Le codage intuitif — qui consiste à décrire ses besoins et à accepter le code généré par un modèle sans analyse approfondie — permet de créer des prototypes en quelques heures et des systèmes fragiles en quelques mois. Ce n'est pas une technique illégitime : c'est une excellente technique pour explorer une idée, mais une technique dangereuse pour développer un système essentiel à une entreprise.
La confusion entre les deux est le problème. Ce qui résulte d'une session de test produit générée par l'utilisateur ressemble beaucoup à un produit : il possède une interface, il répond, il exécute la requête sous les yeux de l'utilisateur. La différence avec un véritable produit ne réside pas dans ses fonctionnalités, mais dans tout ce qui n'a pas encore été défini : que se passe-t-il en cas de dysfonctionnement ? Qui a accès à quelles informations ? Comment le produit évoluera-t-il dans un an ? Et qui comprend la logique de sa conception ?.
|
Dimension |
Prototype généré |
Système en production |
|---|---|---|
|
But |
Pour démontrer que l'idée est possible |
Fonctionner de manière fiable pendant des années |
|
Erreurs |
Elles sont corrigées par régénération |
Ils sont réparés sans endommager le reste |
|
Données |
Testé et nettoyé |
Réel, incomplet, contradictoire |
|
Sécurité |
Hors de portée |
Autorisations, chiffrement, audit |
|
Entretien |
Non applicable |
Le 60-70% du coût total |
|
Propriété du critère |
Le modèle a déterminé la structure |
Quelqu'un a pris cette décision et sait pourquoi. |
La dernière ligne est cruciale à moyen terme. Tant que la structure n'est pas définie, il est impossible de la défendre ou de la faire évoluer. Elle devient alors un texte qui doit être interprété à chaque modification, et cette interprétation prend du temps à chaque changement.
Il ne s'agit pas d'une simple intuition du secteur. GitClear, analysant 211 millions de lignes de code entre 2020 et 2024, a constaté que le travail de refactorisation (réorganisation du code existant pour le rendre compréhensible) est passé d'environ 251 TP3T de modifications totales en 2021 à moins de 101 TP3T en 2024, tandis que le copier-coller est passé de 8,31 TP3T à 12,31 TP3T et que les blocs dupliqués ont été multipliés par huit.
Le rapport DORA 2024 de Google Cloud, basé sur une enquête menée auprès d'environ 39 000 professionnels, a mesuré l'impact sur la livraison : une augmentation de 251 TP3T de l'adoption de l'IA s'est traduite par une baisse de 1,51 TP3T du débit et de 7,21 TP3T de la stabilité. Dans cette même étude, 39,21 TP3T de développeurs ont déclaré avoir peu ou pas confiance dans le code généré.
Le schéma qu'ils décrivent tous deux est identique : la production augmente, la quantité de documents examinés reste la même, et la réorganisation diminue. Les conséquences ne se manifestent pas dès la première semaine ; elles apparaissent lorsqu'un changement s'avère nécessaire.
Il serait insensé de se priver d'un outil qui accélère considérablement l'exploration. Voici les applications où le codage par intuition s'avère clairement le choix idéal :
Dans les quatre cas, il existe une caractéristique commune : Le résultat n'a pas à survivre. Dès l'instant où quelqu'un dit « ça fonctionne presque, mettons-le en production », la catégorie d'utilisation change et les critères doivent changer en conséquence.
Avant de mettre en production un élément généré de cette manière, il est conseillé de répondre à la question suivante :
Un prototype qui répond à cinq questions n'est plus un prototype : c'est un système construit rapidement, ce qui est exactement notre objectif. Le problème n'a jamais été la rapidité.
Le schéma observé lors des audits est toujours le même : une petite équipe réalise en trois semaines ce qui aurait nécessité trois mois. La direction en conclut, à juste titre, que le développement a été moins coûteux. Davantage de projets sont alors approuvés selon les mêmes critères.
Six mois plus tard, chaque modification prend plus de temps que la précédente, personne ne veut toucher à deux modules spécifiques et les estimations ne sont plus fiables. C’est le tableau clinique de la dette technique, que nous avons abordé en détail dans… Le goulot d'étranglement est une fois de plus l'architecture.
Ce qui est frappant, c'est que le diagnostic indique rarement l'origine, car la vitesse initiale était réelle et tout le monde s'en souvient comme d'un succès.
Le schéma observé lors des audits est toujours le même : une petite équipe réalise en trois semaines ce qui aurait nécessité trois mois. La direction en conclut, à juste titre, que le développement a été moins coûteux. Davantage de projets sont alors approuvés selon les mêmes critères.
Six mois plus tard, chaque modification prend plus de temps que la précédente, personne ne veut toucher à deux modules spécifiques et les estimations ne sont plus fiables. C’est le tableau clinique de la dette technique, que nous avons abordé en détail dans… Le goulot d'étranglement est une fois de plus l'architecture.
Ce qui est frappant, c'est que le diagnostic indique rarement l'origine, car la vitesse initiale était réelle et tout le monde s'en souvient comme d'un succès.
Il n'est pas nécessaire de choisir entre générer rapidement et construire efficacement. Les deux phases doivent être distinctes, et vous devez indiquer clairement dans laquelle vous vous trouvez actuellement.
Phase d'exploration. Générez tout ce que vous voulez, sans vérification approfondie, avec des données fictives et sans vous soucier de la maintenance. Le but est d'apprendre.
Point de décision. Quelqu'un déclare l'idée valable. C'est à ce moment-là que se prend la décision que presque personne ne prend : Ce qui a été exploré est jeté aux oubliettes. Ce qui est préservé, c'est le savoir, pas le code.
Phase de construction. L'architecture est définie, le modèle de données est décidé, les contrats sont établis, puis la génération assistée est utilisée, désormais au sein d'une structure définie par une personne.
Jeter le prototype peut sembler un gaspillage, mais il n'en est rien : le prototype a déjà rempli sa fonction, qui était de répondre à une question. Le préserver, c'est transformer un outil d'exploration en fondation d'un édifice.
Cette séparation explique pourquoi, dans TCG-SAF™, l'architecture précède la construction. Non pas par simple formalité : c'est le seul moyen d'exploiter la vitesse de génération sans en hériter du désordre.
Il s'agit de la pratique consistant à générer un logiciel en décrivant ses besoins et en acceptant le code produit par un modèle sans l'examiner en détail. Cette méthode est très efficace pour explorer des idées et créer des prototypes, mais elle pose problème lorsque le résultat est déployé en production sans refonte.
Uniquement si elle répond à cinq questions : quelqu’un peut-il expliquer pourquoi elle est structurée de cette façon, existe-t-il des tests qui détectent les régressions, est-il défini quelles données elle touche et qui peut les consulter, existe-t-il un enregistrement et un mécanisme pour revenir aux opérations normales, et existe-t-il quelqu’un qui peut la maintenir dans un délai d’un an ?.
Les données indiquent une évolution des tendances plutôt qu'une dégradation directe. GitClear a constaté que le volume de refactorisations est passé d'environ 251 TP3T en 2021 à moins de 101 TP3T en 2024, tandis que la duplication a été multipliée par huit. DORA a mesuré une baisse du débit et de la stabilité en 2024, parallèlement à l'adoption croissante de l'IA.
Pour valider une idée avant d'investir, explorez des alternatives d'interface, créez des outils internes éphémères ou apprenez un nouveau domaine. Le point commun ? Le résultat n'a pas besoin d'être pérenne.
Séparer les phases : préserver les connaissances et supprimer le code. Définir ensuite l’architecture, le modèle de données et les contrats, puis réutiliser la génération assistée au sein de cette structure définie par une personne.
Car la vitesse initiale est réelle et reste gravée dans les mémoires comme un succès, tandis que le coût devient évident lorsqu'il faut apporter des modifications : les changements prennent de plus en plus de temps, certains modules sont tabous et les estimations deviennent peu fiables.
Avez-vous un produit en production qui a commencé comme prototype ? Notre audit technique vous indique en 10 jours ouvrables, à prix fixe, ce qui peut être conservé, ce qui doit être restructuré et ce qui engendre des coûts mensuels. Demander l'audit →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
