Une tendance inquiétante émerge dans les équipes d'ingénierie qui ont adopté des outils de codage par intelligence artificielle ces douze derniers mois. Si la première phase est marquée par une euphorie et une vitesse de développement doublée, le troisième mois révèle un problème de maintenable accrue. Bien que les modèles de code s'améliorent et deviennent plus précis, les équipes générant le plus de code sont celles qui doivent effectuer le plus de réécritures. Ce paradoxe s'explique par le « problème de la boîte noire » : le code fonctionne mais son architecture interne reste obscure pour les humains, rendant toute modification risquée et coûteuse. Le code généré par l'IA n'est pas intrinsèquement mauvais, mais il présente des défauts structurels systématiques. Il privilégie souvent les approches monolithiques, regroupant des fonctionnalités distinctes comme le rendu, le traitement et la validation dans un seul fichier. Cette approche empêche l'isolation des tests et la modification sécurisée de parties spécifiques du système. De plus, l'IA crée fréquemment des dépendances circulaires ou implicites car elle se base sur le contexte de la session plutôt que sur un graphe de dépendances global. Il n'y a pas de contrats explicites définis via des interfaces typées, et la documentation générée décrit l'implémentation interne sans expliquer comment utiliser le composant ou quelles sont ses interactions avec le reste du système. Considérons un système de notification. Une génération non structurée produira un seul fichier de 600 lignes mêlant modèles, envoi, préférences et suivi, rendant tout changement complexe. À l'inverse, une génération structurée décompose la fonctionnalité en modules indépendants (modèles, canaux, préférences, livraison, suivi) avec des dépendances déclarées explicitement. La différence n'est pas comportementale, mais architecturale. C'est la composable, ou capacité à construire des systèmes à partir de composants aux frontières définies, qui détermine la maintenabilité à long terme. Le problème fondamental réside dans l'absence de contraintes structurelles lors de la génération. Les flux de travail actuels permettent au modèle de produire du code fonctionnel sans aucune validation architecturale en temps réel. Pour que le code soit naturellement maintenable, l'environnement de génération doit fournir un retour d'information structurel immédiat. Des outils existants permettent déjà d'appliquer ces contraintes lors de la création de code par des humains ; le défi est d'intégrer ces mêmes signaux directement dans le processus de génération par IA. Cela signifie que si l'IA tente de créer un module monolithique avec des couplages cachés, l'environnement le rejette avant la validation, imposant ainsi une architecture solide dès la production du code. La véritable mesure de la productivité de l'IA ne doit pas être la vitesse de génération, mais la rapidité avec laquelle l'équipe peut passer du code généré à une production maintenable. Cela implique trois critères : le code doit être révisable, expédiable et modifiable. Si l'IA économise dix heures de rédaction mais en fait perdre quarante pour la mise en production ou la maintenance future, le gain est illusoire et la dette technique s'accumule. Pour les équipes utilisant actuellement l'IA, il est crucial de traiter chaque demande comme une décision architecturale. Définir clairement les responsabilités, les dépendances et les interfaces publiques dans la consigne permet d'obtenir un bien meilleur résultat qu'une génération ouverte. Il est également nécessaire d'auditer le code existant à la recherche de couplages implicites et de privilégier les outils qui permettent d'évaluer la structure du code généré après sa création. En somme, la solution au problème de la boîte noire ne réside pas dans des invites de prompting améliorées, mais dans la création d'environnements qui imposent la structure lors de la génération. Le code généré par l'IA ne sera maintenable que si l'environnement dans lequel il est produit garantit une architecture composable.