Vous avez eu des freelances. Ils ont livré du code, pas la structure : ce qui manque vraiment
Un freelance livre ce qu'on lui demande : du code, des fonctionnalités, des intégrations. Ce qu'il ne livre pas par défaut, c'est la colonne vertébrale organisationnelle qui donne du sens à ce code. La différence entre les deux explique pourquoi des projets bien codés ne tiennent pas dans la durée.
Donatien Lefranc
Fondateur & Président, Leando
Ce que vous avez reçu, et ce que vous attendiez
Un freelance est un exécutant de haut niveau. Il prend une spécification, il produit du code, il teste, il livre. C'est précisément la valeur pour laquelle on le paie. Ce qu'on ne lui confie pas explicitement, il ne le fera pas, non par manque de compétences mais parce que son périmètre de mission ne l'inclut pas.
Le malentendu naît ici. Quand une PME recrute des freelances pour construire son premier SI ou automatiser ses processus commerciaux, elle attend un résultat qui dépasse la livraison de code : elle attend que son organisation soit mieux structuréeà l'issue du projet. Ce résultat suppose que quelqu'un ait d'abord cartographié les processus, formalisé les règles métier implicites, posé un modèle de données cohérent, et documenté les décisions prises. Ces livrables ne sont pas du code. Ils précèdent et conditionnent le code.
Pourquoi le code sans structure ne tient pas
Un système bien codé sur une structure floue reste fragile. Quand les règles métier n'ont pas été explicitées avant le développement, les développeurs les devinent ou les inventent. Parfois ils devinent juste. Souvent ils s'éloignent des cas particuliers que les équipes opérationnelles connaissent mais n'ont pas pensé à mentionner. Le résultat est un système qui fonctionne pour les scénarios nominaux et craque sur les cas réels, qui représentent souvent 30 à 40 % des situations de terrain.
« Ils avaient déjà démarré notamment avec des freelances, avec une première équipe. Sauf qu'en fin d'année, en faisant le bilan, ils se sont rendu compte qu'ils n'étaient pas assez matures pour avancer sur ces sujets-là, qui partaient un petit peu dans toutes les directions. »
Dans ce cas précis, l'ETI avait mobilisé plusieurs freelances sur des chantiers distincts. Chacun avait avancé dans sa direction, sans vue d'ensemble sur les processus qui devaient finir par se parler. Au bout d'un an, les projets étaient tous en cours, aucun n'était abouti, et les équipes avaient perdu confiance dans la démarche. Ce n'était pas la faute des développeurs : c'était l'absence d'une colonne vertébrale qui aurait dû être posée en amont.
La colonne vertébrale organisationnelle : ce que personne ne livre par défaut
La colonne vertébrale organisationnelle, c'est l'ensemble des éléments qui donnent de la cohérence au projet : le modèle de données qui représente fidèlement les objets métier de l'entreprise, les règles métier formalisées et partagées, les processus cartographiés en notation compréhensible par les équipes et les développeurs, et la documentation des décisions prises au fur et à mesure. Ces éléments ne se codent pas. Ils se construisent dans un dialogue entre le terrain et la technique, avant que quiconque ouvre un éditeur de code.
Ni une agence de développement, ni un freelance, ni une ESN ne livrent cela par défaut. Une agence livre des fonctionnalités selon le cahier des charges qu'elle a reçu. Un freelance livre le périmètre de sa mission. Une ESN livre un produit conforme au contrat.Ce qui manque dans tous ces cas, c'est la capacité à construire le cahier des charges lui-même, en partant du terrain et non d'une intuition dirigeante.
Pour aller plus loin sur ce que devrait inclure un bon cadrage de projet : Les 8 questions à poser avant de choisir un partenaire tech.
Ce que nous livrons que les freelances ne livrent pas
Leando n'est pas un pool de développeurs. La valeur n'est pas dans les lignes de code, c'est dans la capacité à poser les bonnes questions avant d'en écrire une seule. Cela suppose une posture qui combine plusieurs rôles que le marché traite habituellement comme séparés : AMOA stratégique pour verbaliser et formaliser, architecte technique pour penser le modèle de données et la migration progressive, et garde-fou opérationnel pour maintenir la cohérence sous la pression de livrer vite.
« On n'est pas là pour délivrer du code. Notre valeur, c'est la capacité à poser les bonnes questions, à structurer la manière d'avancer et à prendre les bonnes décisions. »
Sur le projet BKW Énergie France, les équipes internes avaient la capacité de coder et disposaient de ressources techniques. Ce qu'elles n'avaient pas, c'étaitla bande passante pour structurer les chantiers avant de les coder. Le travail a consisté à extraire les règles métier spécifiques au secteur de l'énergie (soutirage, injection, TURPE, tarification Enedis), à modéliser les processus en notation BPMN partagée entre le métier et la technique, et à poser un modèle de données robuste avant de démarrer le premier sprint de développement. L'audit interne groupe réalisé en 2026 a validé cette approche, en contraste net avec le bilan de l'année précédente.
Ce qui indique qu'un projet souffre de l'absence de structure
Plusieurs signaux permettent de diagnostiquer ce problème. Le code fonctionne mais les équipes contournent l'outil : elles maintiennent des Excels parallèles parce que l'outil ne couvre pas leurs cas réels. Le système plante sur des situations que les opérationnels considèrent comme normales, mais que personne n'avait formalisées lors du développement. Les développeurs successifs passent un temps significatif à comprendre les décisions du précédent, faute de documentation. Le projet a livré des fonctionnalités mais pas une architecture sur laquelle construire la suite.
Ces signaux apparaissent aussi dans les projets vibe-codés, où l'IA a accéléré la production de code sans que le cadrage organisationnel ait été posé. La dette technique qui en résulte est d'autant plus difficile à traiter qu'elle est souvent invisible jusqu'à la mise en production. Un système vibe-codé peut sembler fonctionnel en démonstration et révéler ses fragilités au premier volume réel. Pour en savoir plus sur ce cas de figure : La posture du médecin plutôt que du vendeur d'outils.
La question à se poser avant de reprendre un projet ou d'en démarrer un nouveau n'est pas « qui va coder ». C'est « qui va poser la structure avant que quiconque code ».Cette décision conditionne tout ce qui suit, y compris la capacité des équipes internes à reprendre le projet de façon autonome après la première livraison.
Pour comprendre comment automatiser un back-office commercial en partant de cette structure : Back-office commercial : comment l'automatiser sans refondre tout le SI.
Certains freelances très expérimentés peuvent poser des bases solides sur des périmètres restreints. Mais livrer une structure organisationnelle complète, c'est-à-dire la formalisation des règles métier implicites, le modèle de données, les processus entre services, et la documentation exploitable par les équipes, demande une posture qui n'est pas celle d'un exécutant. Cela suppose de questionner la demande initiale, de parler à plusieurs interlocuteurs en parallèle, et de documenter ce que personne n'a encore dit. Ce n'est pas un profil de prestation, c'est un profil de partenariat.
Vous avez du code qui ne tient pas. Vous voulez poser la structure.
On commence par un diagnostic honnête de ce qui est récupérable. Ensuite on pose la colonne vertébrale qui manquait, avant de reprendre le développement.
Prendre contact avec Leando