L'IA ne fera pas disparaître la suringénierie. Elle l'accélérera

La suringénierie, c'est résoudre un problème simple d'une manière compliquée : une landing page en microservices, Kubernetes pour dix utilisateurs, une architecture prévue pour un million de requêtes alors que le trafic est modeste. Vous payez, en argent et en temps, une solution sans commune mesure avec le problème lui-même.

C'est ainsi que les incitations sont construites. Une solution complexe se lit comme professionnelle, une solution simple comme inachevée. Personne n'a jamais été licencié pour avoir choisi Kubernetes. On licencie celui qui n'a pas pensé à la montée en charge. Avec une telle asymétrie, se couvrir est rationnel, et les développeurs se couvrent.

L'IA a appris sur du code ouvert et des articles, et ce sont les solutions des grandes entreprises qui y dominent : ce sont elles qui écrivent les blogs, publient les frameworks, donnent le ton. Leurs problèmes sont d'un autre ordre : des millions d'utilisateurs, des centaines de développeurs, des exigences réglementaires.

À la demande « écris une authentification », le modèle rend ce qu'il a rencontré le plus souvent : une structure en couches avec des abstractions, des interfaces et la gestion de scénarios que vous n'aurez jamais. C'est une réponse correcte à la demande moyenne d'internet. Votre projet ne rentre pas dans cette moyenne.

Auparavant, la complication se payait en temps. Écrire cinq couches d'abstraction, c'était une semaine de travail. Vers le troisième jour, on commençait à douter de leur utilité. Le prix faisait office de frein.

Aujourd'hui, ces mêmes cinq couches se génèrent en une minute. Le code se lit bien, les tests passent, la fonctionnalité marche : en apparence tout va bien. Mais le coût principal de la complexité ne porte pas sur l'écriture, il porte sur la maintenance. Dans six mois, il faudra changer quelque chose dans ce code, et c'est alors que la facture arrivera. C'est une dette technique contractée instantanément et sans décision consciente.

Le seul frein naturel à la suringénierie a disparu. Il ne s'agit pas de la qualité de la génération : le code peut être excellent. Il s'agit du fait qu'il est devenu trop bon marché.

Utiliser l'IA comme éditeur

Le scénario courant est tout autre : le développeur demande de générer un module à partir de zéro, reçoit 500 lignes et les colle dans le projet. Personne ne cherchera à savoir ce qui est superflu : le code marche. C'est ainsi que la suringénierie entre dans un projet, en une seule génération.

L'ordre inverse donne un autre résultat :

1. D'abord vous écrivez vous-même. Trente lignes, un JWT simple, une fonction de vérification. En échange, vous comprenez chaque ligne.
2. Ensuite vous le confiez à l'IA pour simplifier. « Voici le code. Retire tout ce sans quoi il continuera de fonctionner. Montre-moi ce qu'on peut jeter. »
3. Vous examinez les propositions. Une partie tombera à côté, mais dans ce mode le modèle travaille mieux : il repère le superflu plus justement qu'il n'invente le nécessaire.

Dans l'édition, il existe un point de repère : votre code et votre compréhension de la tâche. Dans la génération, il n'y a pas de point de repère, et le modèle y substitue la moyenne.

Deux autres méthodes :

• Des contraintes dans le prompt. Si vous générez à partir de zéro, posez le cadre explicitement : « La solution la plus simple qui fonctionne. Sans frameworks, sans couches d'abstraction. SQLite, un seul fichier. »
• Le contexte du projet. La phrase « j'ai 100 utilisateurs et un serveur à dix dollars » change la réponse bien plus que n'importe quelle précision de formulation.

Les entreprises qui ont intégré les agents IA le plus profondément ont bâti autour de la génération toute une couche de contraintes.

Stripe, d'après les descriptions publiques, fait passer plus d'un millier de pull requests par semaine par l'IA. Les tâches confiées aux agents sont formulées de façon étroite : non pas « fais une fonctionnalité », mais une modification strictement délimitée. Les outils accessibles à l'agent sont sélectionnés à la main. Chaque résultat passe par une vérification. L'entreprise a sciemment sacrifié l'ampleur de la tâche au profit de la prévisibilité du résultat.

Chez Google, Shopify et Airbnb, les architectures diffèrent : il n'existe pas de standard unique dans l'industrie, chacun construit selon ses propres risques. Le point commun, c'est que les agents sont insérés dans des processus existants (GitHub, Slack, Linear) et entourés de vérifications.

Aucune d'elles ne prend le résultat de la génération « tel quel ». La valeur vient du cadre posé autour de la génération.

L'IA amplifie ce qui est déjà dans la tête du développeur. Le penchant à compliquer, elle le réalise en quelques secondes ; l'habitude de couper le superflu, tout autant.

La décision selon laquelle ce code est trop complexe pour cette tâche reste prise par un humain. L'IA ne fait que l'exécuter plus vite.