L'IA rembourse la dette technique. Pas la dette de compréhension.
Il y a quelques semaines, j'ai démarré un nouveau projet. Comme souvent maintenant, avec l'IA à mes côtés. Les tickets s'enchaînaient, les fonctionnalités sortaient, tout avançait vite. Très vite.
Puis un matin, un bug.
Je le décris à l'IA. Elle le corrige. Je regarde le diff : plus de 40 fichiers modifiés.
Je teste. Ça fonctionne. Le bug est réglé.
J'aurais pu passer au ticket suivant. Au lieu de ça, je me suis posé une question simple : pourquoi ce bug, et pourquoi fallait-il toucher 40 fichiers pour le corriger ? Et pour y répondre, mon premier réflexe a été… d'ouvrir une conversation avec l'IA pour qu'elle m'explique.
C'est là que j'ai réalisé que je ne connaissais pas mon projet.
Je savais ce qu'il faisait. Je savais quel problème il résolvait, pour qui, et pourquoi. Mais ce qui avait été produit, la structure, les dépendances entre les fichiers, les choix faits ticket après ticket, je n'en maîtrisais presque rien. Le code tournait, et je n'étais plus capable de l'expliquer.
Mon projet était en train de devenir une boîte noire. Il fonctionnait, il avançait vite, il avait fière allure. Mais personne ne savait vraiment ce qu'il y avait dedans, pas même moi.
C'est un piège classique quand on code avec l'IA. Le problème ne vient pas d'un mauvais code. Il vient du fait que plus personne ne le comprend.
Avec l'IA, la vitesse à laquelle on produit du code a explosé. Notre vitesse de compréhension, elle, n'a pas bougé. L'écart entre les deux s'accumule en silence, comme une dette : une dette de compréhension.
Dans un article précédent, j'ai parlé des avantages et des risques du développement avec l'IA. Ici, je veux partager ce que j'ai changé depuis ce matin-là pour garder la main sur mes projets.
Maîtriser le modèle de données
L'IA n'a pas créé le problème. Bien avant elle, beaucoup de développeurs commençaient un projet sans modéliser leur base de données. Les tables arrivaient au fil des besoins.
Avec l'IA, c'est pire. Une table se crée en quelques secondes. Alors on ne prend plus le temps de réfléchir au modèle avant de coder.
Maîtriser son modèle ne veut pas dire tout faire seul, comme avant. L'IA peut aider : proposer une première version, trouver une relation oubliée, signaler un cas limite. Mais le modèle doit être pensé avant le code, compris et validé par vous. L'IA le construit avec vous. Elle ne le décide pas à votre place.
Pour ça, j'utilise toujours UML, avec PlantUML. Avec PlantUML, un diagramme de classes s'écrit comme du texte. Et écrire ce genre de texte, l'IA le fait très bien. Je lui décris le métier, elle me propose un diagramme, je le corrige. Le diagramme est rangé dans le projet, comme le code.
Il ne se passe pas une journée sans que j'utilise PlantUML.
Maîtriser l'architecture
Savez-vous quelle architecture est utilisée dans votre projet ? Quels patterns on y trouve, et quel problème chacun résout ? Avez-vous un schéma clair de la façon dont les parties du projet communiquent ?
Si vous hésitez, vous n'êtes pas seul.
Sans consigne, l'IA choisit une structure à chaque ticket. Un jour, la logique va dans un service. Le lendemain, dans un contrôleur. Au bout de quelques semaines, il y a trois façons de faire la même chose. Et plus personne ne sait où mettre la prochaine fonctionnalité.
Un pattern n'est pas une décoration. Il répond à un problème. Si vous ne savez pas lequel, il n'a peut-être rien à faire dans votre projet.
Là aussi, l'IA peut aider à choisir. Décrivez-lui votre contexte et demandez-lui de comparer plusieurs options. Mais une fois le choix fait, écrivez les règles : où va la logique métier, qui appelle qui, où se branchent les services externes. L'IA n'a plus à deviner. Elle suit.
Enfin, dessinez comment les parties du projet se parlent. PlantUML sert aussi à ça, avec les diagrammes de séquence. Un schéma de vingt lignes explique souvent mieux un bug que 40 fichiers.
Garder la main sur les règles métier
L'IA sait écrire du code. Mais elle ne connaît pas votre métier. Elle ne sait pas comment votre client travaille.
Quand une règle manque, l'IA ne vous prévient pas. Elle invente.
Par exemple, vous demandez : « Le client peut annuler sa commande. » L'IA ajoute un délai de 24 heures, un remboursement automatique et un motif obligatoire. Personne n'a demandé ça. Le code marche, mais personne ne sait d'où viennent ces règles.
Ma règle est simple : une règle métier vient du client, jamais de l'IA. Si une information manque, l'IA doit poser la question, pas deviner la réponse.
J'écris donc les règles avant de coder, fonctionnalité par fonctionnalité : le besoin, les règles, la recette. L'IA s'en sert comme contexte. Je m'en sers pour relire. Et le client peut le valider.
Je garde aussi ces règles dans ICM, la mémoire que j'utilise avec mon agent de code. J'en parle dans ma boîte à outils. Quand une règle est décidée avec le client, je l'enregistre. À la session suivante, l'IA la retrouve toute seule. Je n'ai pas besoin de la répéter à chaque fois.
Le document reste la référence. ICM sert à ce que l'IA s'en souvienne.
Enfin, une règle doit être écrite à un seul endroit dans le code. Si elle est copiée dans plusieurs fichiers, un jour ces copies ne diront plus la même chose. Et une petite correction touchera 40 fichiers.
Avancer par petites étapes
Avec l'IA, on a envie d'aller vite. On demande une grosse fonctionnalité d'un coup, et on reçoit des centaines de lignes.
Le problème, c'est que personne ne relit vraiment un diff de 2 000 lignes. On le survole, on teste, on valide.
Je fais l'inverse. Une demande, un sujet. Un diff que je peux lire en entier.
Je ne laisse pas non plus l'IA faire mes commits. Je relis le diff et je commite moi-même. J'en parle aussi dans ma boîte à outils.
C'est plus lent sur le moment. Mais je sais ce qui entre dans mon projet.
Imposer ses conventions et surveiller ses dépendances
L'IA écrit du code propre. Mais pas forcément votre code. D'un fichier à l'autre, le style change : les noms, la structure, la gestion des erreurs.
Un projet où chaque fichier est écrit différemment devient vite difficile à lire.
J'écris donc mes conventions dans le fichier de contexte du projet. Et pour celles qui comptent vraiment, je ne compte pas sur la bonne volonté de l'IA : un linter les vérifie. Sur un de mes projets, par exemple, la règle « pas de else » est contrôlée automatiquement. Si elle n'est pas respectée, le code ne passe pas.
Comment faire écrire à l'IA du code qui vous ressemble ? Ce sera le sujet de mon prochain article : écrire votre style de code avec l'IA.
Même chose pour les dépendances. L'IA ajoute facilement une librairie « pour simplifier ». Mais chaque librairie, c'est du code que vous n'avez pas écrit, que vous ne connaissez pas, et que vous devrez mettre à jour. Avant d'en accepter une, je me pose une question : est-ce que j'en ai vraiment besoin ?
Documenter les décisions, pas seulement le code
Le code dit ce que fait le projet. Il ne dit pas pourquoi.
Pourquoi cette architecture ? Pourquoi cette table ? Pourquoi cette règle ? Souvent, la réponse est dans une conversation avec l'IA. Et cette conversation disparaît.
Dans six mois, personne ne s'en souviendra. Pas même vous.
J'écris donc chaque décision importante : ce qui a été décidé, et pourquoi. Dans la description de la merge request, dans la documentation du projet, et dans ICM pour que l'IA la retrouve.
Une décision qui n'est écrite nulle part finira par être remise en cause. Souvent par l'IA elle-même.
Savoir déboguer sans l'IA
Revenons à mon bug du début. Mon premier réflexe a été de demander à l'IA de m'expliquer mon propre code.
C'est le vrai signe d'une boîte noire : on ne sait plus corriger sans l'IA.
L'IA reste très utile pour déboguer. Mais je veux pouvoir le faire sans elle. Lire une stack trace. Ajouter un log. Suivre une requête de bout en bout.
Aujourd'hui, quand un bug arrive, je cherche d'abord seul quelques minutes. Pas pour me passer de l'IA. Pour vérifier que je comprends encore mon projet.
Et quand l'IA corrige, je lis la correction jusqu'à comprendre la cause. Si je ne sais pas pourquoi elle a touché 40 fichiers, la correction n'est pas finie.
Conclusion
Si je devais résumer cet article en une phrase : l'IA peut écrire le code à votre place, pas le comprendre à votre place.
Le modèle de données, l'architecture, les règles métier : l'IA peut les construire avec vous, jamais à votre place. Le reste, avancer par petites étapes, garder ses conventions, écrire ses décisions, savoir déboguer, c'est ce qui vous garde maître de votre projet.
Un test simple : prenez un fichier au hasard dans votre projet. Pouvez-vous dire ce qu'il fait, pourquoi il existe, et ce qui casserait si vous le supprimiez, sans demander à l'IA ? Si oui, votre projet n'est pas une boîte noire. Si non, vous savez par où commencer.
L'IA va vite. Mais aller vite ne sert à rien si on ne sait plus ce qu'il y a dans la boîte. Ce matin-là, la mienne n'était pas encore fermée. Ce bug m'a laissé le temps de l'ouvrir.