L'optimisation prématurée à l'ère de l'IA : pourquoi c'est devenu le piège numéro un

L'optimisation prématurée, c'est passer du temps sur des problèmes que vous n'aurez peut-être jamais. Une architecture pour un million d'utilisateurs quand vous en avez douze. La règle qui dit de ne pas le faire est plus vieille que la plupart des langages qu'on utilise, et l'IA vient de la rendre nettement plus difficile à respecter. Avant, sur-construire coûtait des semaines, ce qui calmait tout le monde. Aujourd'hui ça coûte un prompt.

C'est tout le changement, et il est plus grand qu'il n'en a l'air. Le coût de la sur-ingénierie servait de garde-fou. Personne ne partait sur du multi-environnement, une couche de cache et une file de messages pour un produit que personne n'avait encore vu, parce que ça représentait trois semaines que le calendrier ne permettait pas. Ce frein a disparu. Demandez une architecture scalable, et l'IA vous livre des microservices pour zéro utilisateur, avec enthousiasme et sans jamais demander combien vous en avez.

L'ordre n'a pas changé

Trois étapes, dans cet ordre, et l'ordre fait tout le travail.

Construire la bonne chose. Le seul moyen de savoir si c'est la bonne : des retours d'utilisateurs, tôt. Pas un sondage, pas une intuition d'équipe. Quelqu'un qui essaie de s'en servir. Tant que vous n'avez pas ça, chaque heure d'architecture est un pari sur une spécification que personne n'a validée.

La construire simple. Assez propre pour évoluer, pas plus. La solution la plus simple qui marche, pas la plus élégante. C'est là que les gens confondent simple et bâclé : le bâclé crée de la dette, le simple demande justement de comprendre le problème avant d'écrire.

Optimiser quand quelqu'un ressent la lenteur. La performance compte à partir du moment où il y a quelqu'un pour la ressentir. Avant ça, vous optimisez contre une charge imaginaire, et l'imaginaire se trompe presque toujours de goulot d'étranglement.

La règle qui découle des trois : plus vous êtes sûr de construire la bonne chose, plus vous pouvez investir dans l'architecture. Pas l'inverse. La certitude vient d'abord, l'investissement suit. Quand un repo fait le contraire, ça se voit tout de suite.

À quoi ça ressemble dans un repo

Ce ne sont pas des bugs. C'est la difficulté du sujet : rien de ce qui suit ne casse en démo.

Une couche d'abstraction sur la base de données, avec un seul backend derrière et aucun projet d'en ajouter un. Elle a été générée parce que le prompt disait « propre » et que l'IA associe propre à découplé. Résultat, chaque requête traverse deux fichiers de plus, et personne n'ose la retirer parce qu'elle a l'air importante.

Un système de cache pour une page qui reçoit quarante visites par jour. Il fonctionne. Il ajoute juste une classe entière de bugs, ceux où la donnée affichée n'est plus la donnée réelle, sur une page dont la lenteur n'a jamais gêné personne.

Une gestion d'état globale installée à la semaine deux, quand deux composants partageaient une valeur. useState et useEffect couvrent la grande majorité des besoins React réels. La question n'est pas de savoir si le state manager est bon, c'est de savoir s'il résout un problème que vous avez.

Des environnements de staging, de preview et de production configurés avant le premier utilisateur. Trois fois plus de surface de déploiement à maintenir, pour un produit qui n'a encore rien à protéger.

Le point commun : chacune de ces décisions se défend parfaitement dans le prompt qui l'a produite. Aucune ne se défend six mois plus tard, quand le coût réel apparaît sous forme de temps passé à contourner sa propre architecture.

Ce que ça coûte vraiment

Pas de la performance. Du temps, et sur chaque feature suivante.

Un repo sur-construit ralentit tout ce qui vient après, parce que chaque ajout doit respecter des contrats qui n'existaient que pour un futur hypothétique. Vous ne payez pas la sur-ingénierie une fois. Vous la payez à chaque fois que vous touchez au code. C'est exactement l'inverse de l'argument qui l'a justifiée, qui promettait de gagner du temps plus tard.

Et il y a le coût que personne ne compte : les décisions qu'on n'ose plus revenir sur. Un code compliqué que personne ne comprend entièrement devient un code que personne ne simplifie, parce que le risque perçu est trop élevé. La complexité se protège toute seule.

Comment on tranche

Dans notre méthode, l'arbitrage a un endroit précis. Le sprint se planifie en début de semaine, 3 à 5 items, chacun taggé standard ou arch-review selon qu'il touche ou non le registre d'Expandable Core. Ce tag est aussi le filtre anti-sur-ingénierie : si un item n'approche pas le core, il n'a aucune raison de recevoir une architecture. Le core mérite l'investissement parce que tout le reste s'appuie dessus. Le reste mérite de marcher et de partir.

Ensuite, la revue de PR attrape ce qui est passé. L'agent de pre-check signale les violations de convention et détecte les surfaces sensibles, un ingénieur senior relit derrière sous 24h ouvrées. La question qu'on pose le plus souvent en revue n'est pas « est-ce que ça marche », c'est « qu'est-ce qui arrive si on enlève cette couche ». Quand la réponse est « rien », c'est réglé.

Le call hebdo de 60 à 90 minutes sert au reste, les arbitrages qui ne rentrent pas dans un commentaire de PR. C'est là que se décide ce qu'on accepte de construire en avance, et pourquoi.

---

Vous voulez savoir ce que votre codebase a construit pour un problème que vous n'avez pas ? On fait un Bunker Test gratuit : accès au repo, audit écrit, retour sous cinq jours ouvrés. Sans engagement.

Demander le Bunker Test