Pourquoi la dette technique en entreprise commence par un mauvais brief

Au fil de mes années de travail en entreprise – d'abord chez « Alkar » dans les années 90, puis chez « Dom i Sad », et maintenant avec formspace.design – j'ai maintes fois constaté que la racine de la plupart des problèmes de développement, d'automatisation et même de tâches simples réside dans un mauvais brief. La dette technique, c'est-à-dire les problèmes accumulés dans le code ou le système qui ralentissent le développement, ne commence pas avec les « mains gauches » du programmeur, mais avec une demande mal formulée. C'est ma conviction profonde, basée sur des décennies de pratique, de définition de tâches et de refontes ultérieures.

Pourquoi un mauvais brief est le fondement de la dette technique

Imaginez : vous construisez une maison. Mais au lieu d'un projet et d'un plan clairs, vous dites aux constructeurs : « Faites quelque chose de beau, spacieux et confortable. » Que construiront-ils ? Quelque chose qui correspond à leurs idées de beauté, d'espace et de confort, mais pas nécessairement aux vôtres. Dans les projets informatiques, cela se manifeste encore plus fortement. Un programmeur est un exécutant qui travaille avec la logique et les algorithmes. S'il reçoit un cahier des charges (CdC) vague, il doit imaginer les détails, prendre des décisions à la place du client. Ces « suppositions » sont les premières briques de la dette technique.

Je me souviens qu'au début des années 90, lorsque nous commencions à implémenter des logiciels de comptabilité de gestion chez « Alkar », j'ai moi-même commis cette erreur. Il me semblait que les programmeurs « devaient comprendre » mes besoins. En conséquence, nous passions des semaines, voire des mois, à développer des fonctionnalités qu'il fallait ensuite refaire, car elles ne correspondaient pas tout à fait aux processus métier réels. Chaque refonte n'est pas seulement du temps perdu, c'est un manque à gagner, une démotivation de l'équipe et, en fin de compte, de l'argent réel. Selon mes observations, modifier le CdC de 30 % à mi-chemin d'un projet peut doubler les délais et le budget. Ce sont d'énormes pertes qui peuvent être évitées.

Signes d'un mauvais brief : comment les reconnaître dès le départ

Reconnaître un brief de mauvaise qualité dès le début, c'est déjà la moitié du succès. Voici quelques signaux d'alarme auxquels je prête toujours attention :

1. Manque de spécificité. Des phrases comme « rendre pratique », « rendre moderne », « améliorer l'efficacité » sans indicateurs chiffrés ou critères d'évaluation clairs. Que signifie « pratique » ? Pour qui ? Comment ?
2. Exigences contradictoires. Quand un point du CdC dit une chose, et un autre point, l'exact opposé. Ou lorsque différents stakeholders donnent des informations différentes et qu'elles ne sont pas harmonisées.
3. Incompréhension de l'objectif. Si le client ne peut pas formuler clairement quelle tâche métier le produit ou la fonction doit résoudre, quel résultat il s'attend à obtenir à la fin.
4. Changements fréquents en cours de processus. Bien sûr, l'environnement commercial évolue, mais si les exigences sont radicalement revues chaque semaine, c'est la voie royale vers le chaos et les refontes interminables. C'est l'exemple classique du « on a d'abord fait X – puis on a refait », que j'ai vu des centaines de fois.
5. Absence de priorités. Quand toutes les fonctions sont également importantes, et qu'il n'y a pas de compréhension de ce qui doit être fait en premier pour un produit minimum viable (PMV).

Comment j'ai appris à formuler des tâches pour les programmeurs

Mon parcours, de « directeur qui veut quelque chose » à fondateur de formspace.design, qui définit lui-même les tâches (parfois même pour lui-même, avec l'aide de l'IA), a été long et semé d'embûches. Chez « Alkar », j'ai compris qu'il fallait se plonger dans les détails. Chez « Dom i Sad », en gérant des projets de construction et d'aménagement paysager, j'ai appris à décomposer les grandes tâches en étapes plus petites et mesurables. C'est à ce moment-là que j'ai commencé à appliquer les principes qui allaient plus tard former la base de mon approche du travail avec l'automatisation et l'IT.

J'ai commencé à exiger de moi-même et de mes managers :

• Une description claire du résultat souhaité : Que doit-il se passer lorsque l'utilisateur effectue une action ? Quelles données doivent changer ? À quoi cela ressemble-t-il ?
• Captures d'écran, prototypes, schémas : La visualisation en dit souvent plus que mille mots. Même une maquette dessinée à la main aide à éviter l'ambiguïté.
• Exemples de données : À quoi doivent ressembler les données d'entrée et de sortie ? C'est crucial pour le bon fonctionnement du système.
• Compréhension du processus métier : Si le programmeur comprend l'objectif d'une fonction donnée, il peut proposer une solution plus optimale ou détecter des erreurs logiques dans le CdC.

Cela ne signifie pas que je suis devenu programmeur. Plutôt, j'ai appris à parler un langage qui permet au développeur de comprendre précisément ma pensée. Mon expérience de travail avec l'IA, que j'ai décrite dans l'article Comment l'IA m'aide à gérer formspace.design sans grande équipe, ne fait que confirmer cette thèse : plus mon prompt est précis et détaillé, meilleur est le résultat.

Check-list pour la rédaction d'un brief efficace

Pour éviter la douleur et la dette technique que j'ai rencontrées, je recommande d'utiliser la liste de contrôle suivante lors de la préparation d'un brief :

1. Définissez l'objectif : Quel problème le projet résout-il ? Quel résultat est attendu ? (Par exemple : « Réduire le temps de calcul d'un devis de 3 heures à 15 minutes »).
2. Décrivez le public cible : Qui utilisera le produit ? Quels sont leurs besoins et leurs contraintes ?
3. Formulez la liste des fonctions (exigences fonctionnelles) : Que doit faire exactement le système ? Chaque action de l'utilisateur, chaque réaction du système. (Par exemple : « L'utilisateur peut télécharger une photo du terrain », « Le système génère 3 options d'aménagement paysager »).
4. Indiquez les exigences non fonctionnelles : Performance, sécurité, facilité d'utilisation, évolutivité. (Par exemple : « La page doit se charger en moins de 2 secondes », « Le système doit traiter jusqu'à 1000 requêtes par heure »).
5. Dessinez des prototypes ou des schémas : À quoi ressemble l'interface ? Comment l'utilisateur navigue-t-il dans le système ? Cela peut être un croquis sur papier ou une maquette complète dans Figma.
6. Indiquez les technologies utilisées et les intégrations (le cas échéant) : Avec quels autres systèmes le produit doit-il interagir ?
7. Définissez les délais et le budget : Des cadres réalistes pour le projet.
8. Désignez les responsables : Qui, du côté du client, acceptera le travail, répondra aux questions, donnera des retours ?
9. Effectuez une revue du brief : Laissez plusieurs personnes du côté du client et de l'exécutant lire et discuter du document pour identifier les ambiguïtés et les contradictions avant le début du travail.

Conséquences d'un brief de mauvaise qualité pour l'entreprise

Le coût d'un mauvais brief est élevé et se mesure non seulement en argent, mais aussi en temps, en réputation et même en moral de l'équipe. J'ai vu des projets s'étirer sur un an ou deux, voire échouer complètement, à cause d'un manque de clarté initial. Selon mes estimations, chaque rouble « économisé » lors de la phase de briefing se transforme en dix lors des ajustements et des refontes.

• Pertes financières : Heures de travail supplémentaires des programmeurs, paiement pour les refontes, manque à gagner dû au lancement tardif du produit.
• Perte de temps : Les projets dépassent les délais, ce qui peut entraîner une perte d'avantage concurrentiel.
• Faible qualité du produit : Si les exigences n'étaient pas claires, le produit final peut ne pas résoudre les problèmes réels des utilisateurs ou être difficile à utiliser.
• Démotivation de l'équipe : Les refontes constantes et l'absence d'objectifs clairs épuisent à la fois le client et l'exécutant, réduisant la productivité et l'envie de travailler sur le projet.
• Risques de réputation : Les projets infructueux peuvent nuire à la réputation de l'entreprise cliente et de l'exécutant. Après tout, comme je l'ai écrit dans l'article Histoire typique : j'ai commandé une chose, j'en ai reçu une autre, j'ai payé deux fois, c'est un problème fréquent auquel beaucoup sont confrontés.

formspace.design et les leçons du passé : comment nous évitons la dette technique

Lorsque j'ai commencé à créer formspace.design, j'ai compris à quel point il était important d'éviter les erreurs du passé. Je ne suis pas un programmeur professionnel, mais mes nombreuses années d'expérience en affaires et en aménagement paysager m'ont appris la valeur d'une planification claire. Je développe moi-même formspace.design, en utilisant l'IA comme un outil puissant, et cela n'a été possible que parce que j'ai appris à formuler mes idées de la manière la plus concrète possible. Les modules de formspace.design sont créés en tenant compte de ce principe.

Par exemple, lorsque je planifie une nouvelle fonction, que ce soit dans les modules de planification (1.x plan/zones/objets) ou dans le bloc de concept IA (2.1 AI concept), je travaille d'abord moi-même sur le scénario d'utilisation dans les moindres détails. J'imagine ce que l'utilisateur fera, quelles données il saisira, quel résultat il attendra. Pour le module 3.1 « Design par photo », cela signifie la définition précise des paramètres de traitement d'image, des styles possibles, des éléments que l'IA doit reconnaître et modifier. J'enregistre ces étapes, dessine des prototypes et ce n'est qu'après cela que je commence à écrire le code (ou les prompts pour l'IA). Cela me permet d'éviter les « suppositions » lors de la phase de réalisation et de minimiser la dette technique, même en travaillant sans équipe de programmeurs, comme je l'ai partagé dans À quoi ressemble une journée où je programme sans être programmeur.

Questions fréquentes

Peut-on éviter complètement la dette technique ?

Il est probablement impossible d'éviter complètement la dette technique, car elle peut survenir pour diverses raisons, y compris les changements de technologies ou d'exigences commerciales. Cependant, elle peut être minimisée et gérée efficacement grâce à un briefing de qualité, un refactoring régulier et une planification stratégique. L'essentiel est d'aborder chaque tâche de manière consciente et de ne pas reporter à plus tard la résolution des problèmes connus.

Que faire si le client ne peut pas fournir un brief clair ?

Dans une telle situation, la tâche du manager ou de l'analyste est d'aider le client à formuler ses exigences. Cela peut inclure la tenue d'ateliers, d'entretiens, l'étude des processus métier et la création de prototypes. Il est important de poser des questions suggestives, de proposer des options et d'obtenir des précisions avant de confier la tâche au développement. C'est un investissement de temps qui sera rentabilisé de nombreuses fois.

Un brief détaillé garantit-il toujours le succès d'un projet ?

Un brief détaillé augmente considérablement les chances de succès, mais ne le garantit pas à 100 %. La qualification des exécutants, une gestion de projet efficace, une évaluation adéquate des risques et la volonté de communiquer sont également importantes. Cependant, l'absence d'un brief détaillé conduit presque toujours à des problèmes, tandis que sa présence constitue une base solide.

Comment distinguer la dette technique des besoins habituels d'améliorations ?

La dette technique est un « crédit » impayé, contracté pour gagner en vitesse, mais qui exige ensuite un remboursement. Elle se manifeste par un code non optimal, des solutions temporaires, un manque de documentation, ce qui entrave le développement ultérieur. Les améliorations habituelles sont le développement planifié du produit, l'ajout de nouvelles fonctionnalités ou l'amélioration des existantes, qui ne sont pas causées par des erreurs ou des solutions de mauvaise qualité du passé.

En tant que dirigeant, dois-je comprendre les détails techniques pour rédiger un brief ?

Il n'est pas nécessaire d'être programmeur, mais une compréhension des principes fondamentaux du fonctionnement du système et de la manière dont vos décisions affectent la mise en œuvre technique est très utile. Mon parcours vers formspace.design a montré qu'une expertise approfondie du domaine, combinée à la capacité de formuler clairement les tâches, est plus importante que la connaissance des langages de programmation. L'essentiel est de savoir traduire les besoins métier en exigences compréhensibles pour les développeurs.

À quelle fréquence faut-il revoir et actualiser le brief ?

Le brief est un document vivant qui peut et doit s'adapter aux conditions changeantes. Cependant, les changements radicaux doivent être minimisés et effectués de manière consciente, en comprenant les conséquences. Pour les projets à long terme, il est recommandé d'effectuer des revues régulières du brief (par exemple, une fois par trimestre) et d'enregistrer toutes les modifications afin que l'équipe travaille toujours avec des informations actualisées.

Peut-on utiliser les méthodologies Agile pour un briefing flexible ?

Les méthodologies Agile sont excellentes pour une approche flexible du développement et peuvent aider à éviter un brief rigide et obsolète. Cependant, même en Agile, des user stories claires et des critères d'acceptation sont nécessaires pour chaque itération. Sans eux, même avec une approche flexible, il est facile de tomber dans l'ambiguïté et l'accumulation de dette technique.

Conclusion

Mon expérience m'a convaincu : un brief de qualité n'est pas une simple formalité, mais une étape cruciale qui détermine le succès de l'ensemble du projet. En fin de compte, c'est votre plan d'investissement pour le développement de votre entreprise. Ne lésinez pas sur le temps et les efforts pour le rédiger, et vous en économiserez bien plus à l'avenir. La clarté et la spécificité au départ sont la clé d'un développement stable et d'une minimisation des risques. C'est une leçon que j'ai apprise au fil des décennies et que j'applique maintenant à la création de formspace.design.