Sur Dijon, la question qui revient le plus souvent dans les demandes que nous recevons n'est pas quelle technologie choisir, mais à qui confier le projet : un développeur indépendant ou une équipe. Voici comment nous y répondons concrètement, ce que nous regardons avant d'établir un devis, et les arbitrages techniques que nous posons noir sur blanc avant la première ligne de code.
Freelance ou agence à Dijon : la vraie ligne de partage
La comparaison entre indépendant et agence revient dans presque toutes les demandes qui nous arrivent, parce que ce qui se joue derrière est une question de risque. Un indépendant convient très bien à un périmètre stable et bien décrit : un site de présentation, une intégration ponctuelle, un renfort sur une équipe qui dispose déjà d'un référent technique en interne. Le point de vigilance est la continuité. Si la personne devient indisponible ou change de mission, le projet s'arrête, et le code se reprend mal faute de documentation. Une structure plus large apporte cette continuité, mais ajoute des couches (chef de projet, commercial, sous-traitance) qui éloignent le décideur de celui qui écrit réellement le code. Go To Agency se situe volontairement entre les deux : deux cofondateurs, Robin Monteiro sur le développement Next.js et React, Florian Loppion sur l'acquisition et la visibilité. Vous écrivez à la personne qui code, sans intermédiaire, et le volet visibilité est traité par quelqu'un qui n'a pas à redécouvrir le projet. Si votre besoin est vraiment une prestation courte et cadrée, un indépendant fera l'affaire et nous vous le dirons. Si le projet doit vivre, évoluer et être repris plus tard par quelqu'un d'autre, l'arbitrage se joue sur la reprise du code, pas sur le statut juridique du prestataire.
À qui vous avez affaire quand vous cherchez un développeur en Côte-d'Or
Une entreprise de Côte-d'Or qui cherche un prestataire technique tombe en pratique sur trois familles. Les sociétés de services orientées régie, qui facturent des journées d'ingénieur et s'adressent surtout aux grands comptes et aux organismes publics. Les agences de communication qui font du web en complément de leur métier, souvent sur un CMS grand public ou un constructeur de pages : très bien pour un site de présentation, vite limitées dès qu'il faut un espace client, un calcul métier ou une connexion à un logiciel existant. Et les indépendants, dont le niveau technique va de l'excellent au très inégal. Le vide se situe entre ces extrêmes : un projet trop technique pour une simple vitrine, trop réduit pour une société de services. C'est le segment sur lequel nous travaillons, et nos réalisations (Mediavocats, LB Athletic, Au Petit Détail) recouvrent des besoins qui n'ont pas grand-chose en commun. Autre réalité locale : beaucoup de dirigeants bourguignons ont déjà un logiciel de gestion, un ERP ou un outil métier en place et n'ont aucune envie d'en changer. Le sujet n'est donc presque jamais de repartir d'une page blanche, mais de brancher proprement le web sur ce qui tourne déjà.
Comment un projet technique se cadre entièrement par écrit
Tout se traite par écrit et de façon asynchrone. Ce n'est pas une contrainte d'organisation : c'est ce qui oblige à formuler le besoin précisément, des deux côtés. Vous décrivez votre besoin avec vos mots, vos captures d'écran, vos exports, vos exemples de sites concurrents. Nous répondons sous 24 heures ouvrées avec une lecture concrète : ce qui nous paraît clair, ce qui ne l'est pas, ce qui demandera plus de travail que vous ne l'imaginez et ce qui en demandera moins. Un cadrage écrit laisse une trace consultable des mois plus tard, ce qu'aucune conversation orale ne permet. Cela évite le désaccord classique de fin de projet, où chacun se souvient d'une version différente de la même décision. La séquence reste toujours la même : compréhension du besoin, périmètre écrit et découpé en lots, choix technique argumenté (rendu serveur ou statique, base de données, hébergement, dépendances), puis développement par incréments visibles sur une préproduction que vous ouvrez quand vous voulez. Les retours se font page par page sur cette préproduction, jamais sur un document théorique que personne ne relit.
Ce qui fait varier l'effort, et donc le devis
Un devis de développement dépend d'éléments très identifiables, que vous pouvez préparer avant même de nous écrire. Le nombre de gabarits réellement distincts compte davantage que le nombre de pages : un site volumineux bâti sur quelques modèles communs demande moins de travail qu'une poignée de pages toutes singulières, chacune avec sa mise en page. Les intégrations pèsent lourd : paiement, prise de commande, connexion à un logiciel de gestion, synchronisation d'un catalogue, export comptable. Chaque connexion à un système tiers oblige à lire sa documentation, à gérer ses erreurs et à tester des cas limites que personne n'avait anticipés. La reprise de données existantes reste le poste le plus sous-estimé : récupérer un ancien catalogue mal structuré demande souvent plus de temps que de construire l'interface qui l'affichera. Viennent ensuite le multilingue, l'accessibilité (sujet obligatoire dès qu'une collectivité ou un organisme public est concerné), le niveau d'exigence sur les performances et la question de savoir qui fera vivre le site ensuite. Nous n'établissons jamais de devis avant d'avoir ces réponses : une estimation donnée trop tôt est soit une marge de sécurité que vous payez pour rien, soit une mauvaise surprise pour tout le monde.
Les erreurs que nous retrouvons le plus souvent sur les projets existants
Les mêmes problèmes reviennent d'une reprise de projet à l'autre. Le premier : personne ne détient les accès. Nom de domaine enregistré par un ancien prestataire, dépôt de code introuvable, hébergement au nom d'un salarié parti depuis longtemps. Réunissez vos accès avant toute autre chose, c'est le point de départ de toute reprise sérieuse. Le deuxième : un site construit par empilement d'extensions, où chaque mise à jour devient un pari et où plus personne n'ose toucher à rien. Le troisième : l'absence d'environnement de test, qui oblige à modifier directement le site en ligne, avec le résultat que l'on imagine un vendredi en fin de journée. Le quatrième, le plus coûteux en visibilité : une refonte livrée sans plan de redirection, qui change toutes les adresses de pages et efface d'un coup un référencement construit sur des années. Le cinquième : un site rapide le jour de la livraison, jamais mesuré ensuite, alourdi mois après mois par des images non compressées et des scripts de suivi ajoutés au fil des campagnes. Aucun de ces points n'est une fatalité technique. Ce sont des sujets d'organisation, qui se règlent au moment du cadrage.
