Réécrire un projet avec l’IA: plus d’une cinquantaine de régressions malgré une documentation complète

Résumé

L’application fonctionnait et avait connu un vrai succès, mais une seule personne savait vraiment la faire tourner, et elle ne pouvait pas assurer une disponibilité 24 heures sur 24. Le transfert était donc légitime. La reprise devait se faire dans une autre stack technique, et le choix s’est porté sur une réécriture assistée par l’IA. Celle-ci partait de bien plus qu’un dépôt de code: documentation technique et fonctionnelle, spécifications à jour, historique des migrations, bonne couverture de tests. Le résultat livré en qualification présentait un design médiocre et plus d’une cinquantaine de régressions de gravité variable.

Je n’y vois pas la preuve que l’IA est incapable de réécrire un logiciel, et je n’impute pas chaque régression au seul modèle: la méthode, les consignes, les contrôles et les décisions humaines pèsent aussi sur le résultat. La leçon est qu’une réécriture n’est pas une traduction. Les comportements, les règles métier et les contrats d’API sont à préserver; l’architecture, la gestion des erreurs, la concurrence et les bibliothèques sont à concevoir pour la stack cible. Décider de ce qui reste identique et de ce qui évolue est un travail de conception: l’IA peut y contribuer, mais la décision revient à l’équipe.

Reste une question plus difficile: que se passe-t-il quand la connaissance n’a jamais été écrite? L’IA peut analyser le code et formuler des hypothèses, mais elle ne peut pas préserver une règle qu’aucun document, aucun test ni aucune trace ne révèle. Une génération rapide risque alors de transformer une dette de connaissance en dette technique. L’article propose enfin une démarche contrôlée en six étapes, six stratégies de réécriture choisies selon la connaissance disponible et l’écart entre les stacks, et pose la question de qui porte la responsabilité du résultat.

Idées clés

• Une documentation, des spécifications et des tests complets n’ont pas empêché plus d’une cinquantaine de régressions: disposer de l’information ne garantit pas qu’elle sera correctement exploitée.
• Réécrire n’est pas traduire: les comportements se préservent, l’architecture se conçoit pour la stack cible.
• La qualification n’est pas une formalité de fin de parcours: les critères de réussite et les contrôles indépendants se définissent dès le début de la migration.
• Quand les règles métier n’existent que dans la mémoire de quelques personnes, l’IA ne peut pas préserver ce qu’aucune information disponible ne révèle, et une génération rapide peut transformer la dette de connaissance en dette technique.
• Transférer le code n’est pas transférer la responsabilité: le vrai indicateur de réussite est une équipe capable de livrer un système fiable et de le maintenir dans la durée.

Pourquoi j’ai écrit cet article