Par Ion Anghel · Avril 2026
Un CTO m'a appelé le trimestre dernier. Son pitch, en gros : « On est en retard sur l'IA. Je veux tous les ingénieurs sur Copilot d'ici la fin du mois, et je veux voir la vélocité monter. » Je lui ai posé trois questions. Vous avez des tests ? « Quelques-uns. » Vous avez une CI qui bloque les mauvais merges ? « En quelque sorte. » Quand a eu lieu la dernière fois où un senior a fait une vraie revue de bout en bout sur la PR d'un junior ? Longue pause.
Il n'avait pas un problème d'IA. Il avait un problème de codebase, un problème de processus et un problème de recrutement empilés l'un sur l'autre. Acheter des licences Copilot allait aggraver les trois, plus vite.
Je veux être clair dès le départ, parce que la suite va sonner comme du scepticisme et ne l'est pas : je considère que l'ingénierie assistée par IA est l'une des évolutions les plus importantes de notre métier depuis vingt ans. Je l'utilise tous les jours. J'expédie plus grâce à elle. Le propos de cet article n'est pas que l'IA est survendue — c'est que l'IA est vendue comme solution à des problèmes qu'elle ne résout pas, et cette confusion coûte aux équipes de l'argent bien réel.
L'IA est un amplificateur, pas un outil de réparation
Les grands modèles de langage, et les agents construits par-dessus, font une chose très bien : ils prolongent les motifs qu'ils voient. Donnez-leur un module propre avec un nommage cohérent, des types corrects et des tests à côté, et ils l'étendront dans le même esprit. Donnez-leur un contrôleur de 200 lignes avec trois styles différents de gestion d'erreurs, un singleton global mutable et de la concaténation de chaînes en SQL, et ils vous produiront fidèlement encore plus exactement de cela. Le modèle ne va pas s'opposer en disant « en fait, cette classe a trop de responsabilités, laissez-moi refactorer d'abord. » Il va se conformer à la pièce.
C'est la partie sur laquelle aucun pitch commercial ne s'attarde. L'IA n'a pas de goût sur votre codebase. Elle a des statistiques sur votre codebase. Si les statistiques sont mauvaises, la sortie est mauvaise — sauf qu'il y en a plus, maintenant, et que ça part en production plus vite.
On le ressent dans n'importe quel monorepo un peu ancien. Lancez un agent sur un module legacy et regardez ce qui en sort : du code écrit avec assurance, qui semble plausible, qui utilise les helpers existants, qui suit les anti-patterns existants et qui passe les tests faibles existants. La CI est verte. La PR est petite. Elle est mergée. Six semaines plus tard, vous pagez quelqu'un à 2h du matin à cause d'une race condition que l'agent n'avait aucun moyen de connaître, dans un système qu'il n'avait aucun moyen de modéliser.
Le remède ici n'est pas d'interdire l'agent. Le remède est d'admettre que le codebase ne pouvait pas porter cette vélocité au départ.
La sécurité, c'est là que ça fait mal en premier
Au fil des années, j'ai audité un certain nombre de plateformes web petites à moyennes, et la même poignée de problèmes revient presque à chaque fois. Des clés d'API commitées dans Git, souvent retrouvables dans l'historique public. Des fichiers .env servis depuis le webroot parce que quelqu'un a mal configuré une règle de répertoire. Des webhooks qui acceptent n'importe quel POST parce que la vérification de signature était « TODO ». De l'input utilisateur qui coule sans traitement dans du SQL, ou dans des commandes shell, ou dans des templates que le framework rend joyeusement en HTML. Des flags de consentement RGPD qui existent dans l'UI mais que le backend ne lit jamais.
Aucun de ces problèmes n'a été créé par l'IA. Ils la précèdent de plusieurs décennies. Mais voici ce que l'IA change : elle abaisse drastiquement le coût d'ajout de code neuf, et la plupart des équipes n'ont pas d'investissement correspondant dans l'augmentation du coût d'ajout de code non sécurisé. Donc les mêmes motifs sont reproduits, plus vite. L'agent voit que les contrôleurs existants ne valident pas l'input, et écrit un nouveau contrôleur qui ne valide pas l'input. L'agent voit que les secrets sont chargés depuis un .env tracké dans Git, et utilise ce motif avec confiance dans un nouveau service. L'agent n'est pas imprudent. Il est cohérent. Avec un codebase qui était déjà imprudent.
J'ai écrit sur une version spécifique de ce mode d'échec dans From Vibe Coding to Insecure Keys — un projet poussé du prompt à la production en un week-end, avec les credentials dans le bundle navigateur. Ce n'est pas un bug d'IA. C'est un trou de processus que l'IA a rendu assez bon marché pour être exposé à l'échelle.
Sans tests et sans CI, la vélocité n'est que du risque
Il y a une conversation que j'ai régulièrement avec des responsables d'ingénierie. Ils veulent mesurer l'adoption de l'IA par le débit de PR, ou par les lignes de code, ou par les tickets Jira fermés. Tout cela mesure une seule chose : à quelle vitesse vous poussez du code dans le système. Aucune de ces métriques ne mesure si ce code aurait dû entrer.
Si vous n'avez pas de tests, vous n'avez pas de feedback. Si vous n'avez pas de CI qui exécute ces tests à chaque changement et bloque les merges en cas d'échec, vous n'avez pas de filet de sécurité. Si vous n'avez pas de code review où un deuxième humain lit effectivement le diff et pousse en arrière, vous n'avez pas de filtre qualité. Empilez un agent IA là-dessus, et ce que vous avez construit est un itinéraire plus rapide entre l'idée et l'incident.
Les équipes qui obtiennent un vrai levier de l'IA ne sont pas celles qui l'ont adoptée le plus agressivement. Ce sont celles qui avaient déjà le côté ennuyeux en place — une suite de tests qui tourne en moins de dix minutes, un pipeline de déploiement depuis lequel on peut roll back en un clic, du alerting qui page un humain avant que les clients tweetent. L'IA comprime le travail entre les garde-fous. Elle ne remplace pas les garde-fous.
Le « vibe coding » ne passe pas au-delà du démo
Il existe un mode de travail — rapide, conversationnel, qui fait largement confiance au modèle — qui est vraiment merveilleux pour des prototypes, des outils internes, des projets de week-end, l'apprentissage de nouvelles stacks. Je le fais en permanence. C'est ainsi que beaucoup de logiciels utiles voient le jour.
C'est aussi catastrophiquement inapproprié pour tout système qui manipule des données utilisateurs réelles, de l'argent, ou des credentials tiers, déployé par quelqu'un qui ne va pas lire personnellement chaque ligne avant qu'elle parte. La raison n'est pas que le modèle est mauvais. La raison est que le « vibe coding » désactive délibérément les vérifications — vous ne lisez pas le diff attentivement, vous ne pensez pas en mode adverse sur les entrées, vous ne vous demandez pas « qu'est-ce qui se passe si ça échoue ». Ces vérifications sont exactement ce dont le code de production a besoin en plus, pas en moins.
L'erreur que certaines entreprises font en 2026 est de prendre un workflow excellent pour un hackathon et d'essayer de faire tourner une activité avec. Ça ne marche pas.
Le vrai problème n'est presque jamais technologique
Voici l'observation inconfortable à laquelle j'arrive sans cesse. Quand une équipe de direction achète une flotte d'outils IA pour « transformer » son organisation d'ingénierie, l'IA n'est souvent pas l'achat réel. L'achat réel est l'évitement de trois conversations beaucoup plus difficiles.
La première porte sur la dette technique — celle qui demande de dire à voix haute, devant le conseil d'administration, que la plateforme qu'on célèbre depuis cinq ans pourrit en dessous et que quelqu'un doit passer un trimestre à la nettoyer. La deuxième porte sur le recrutement — que le niveau a baissé, qu'il y a des gens dans l'équipe qui n'auraient pas dû être recrutés ou promus, et qu'aucune quantité d'outils ne répare une équipe qui ne sait pas à quoi ressemble le « bon ». La troisième porte sur les standards — que l'organisation ne s'est jamais mise d'accord sur ce que veut dire « fini », sur quels tests sont obligatoires, sur ce qu'une revue doit effectivement attraper, et que tout le monde a fonctionné au goût personnel pendant des années.
L'IA est marketée comme un moyen de sauter ces conversations. Elle ne l'est pas. Elle est juste un moyen de faire arriver leurs conséquences plus vite.
Quand l'IA mérite vraiment sa place
Je veux finir sur ce qui marche, parce que beaucoup de choses marchent.
Sur un codebase sain — avec des frontières de modules propres, des types corrects, une vraie suite de tests, de l'observabilité qu'on peut effectivement lire — l'assistance IA est véritablement transformatrice. Un refactor sur des dizaines de fichiers devient une tâche d'une demi-heure au lieu d'un sprint. Écrire des tests pour du code déjà bien structuré devient agréable plutôt que pénible. La documentation que personne n'avait le temps d'écrire est générée puis tronquée à l'essentiel. La code review gagne une deuxième paire d'yeux qui ne fatigue jamais et qui attrape la classe ennuyeuse de bugs que les humains ratent à 17h. L'analyse exploratoire sur un jeu de données qu'on n'a jamais touché devient une conversation au lieu d'un après-midi sur Stack Overflow.
Dans chacun de ces cas, le levier vient de la même source : la fondation était assez solide pour que le modèle amplifie dans la bonne direction. L'IA n'a rien réparé. Elle a accéléré un travail déjà correct.
Ce qu'il faut faire lundi matin
Si vous êtes sur le point de déployer du tooling IA sur toute votre organisation d'ingénierie, il n'y a qu'une seule chose que je vous demanderais de faire avant. Ouvrez les trois derniers incidents de production et lisez les post-mortems honnêtement. Ont-ils été causés par quelque chose qu'un LLM aurait pu prévenir — une faute de frappe, un null check oublié, un import manquant ? Ou ont-ils été causés par quelque chose de plus structurel — pas de test sur ce chemin, pas d'alerting sur ce signal, pas de revue sur cette PR, un service que personne d'astreinte ne comprenait ?
Si c'est la deuxième catégorie — et c'est presque toujours le cas — alors la chose à plus fort levier que vous pouvez faire ce trimestre n'est pas un déploiement de Copilot. C'est une suite de tests qui tourne sur chaque PR. C'est une page écrite qui définit ce que « fini » veut dire pour votre équipe. C'est vingt minutes de binôme entre un senior et un junior sur la code review, chaque semaine, jusqu'à ce que le niveau soit partagé.
Faites ça, et ensuite faites entrer l'IA. Elle se remboursera au décuple, parce qu'elle aura enfin quelque chose qui mérite d'être amplifié.
Disclaimer : je suis bullish sur l'IA. Je pense que la plupart des aspérités que je décris seront lissées dans les prochaines années, et je pense que les ingénieurs qui apprennent à travailler aux côtés de ces outils livreront plus que ceux qui ne le font pas, avec une marge confortable. Mais le chemin vers cet avenir passe par la discipline d'ingénierie, pas autour. Les équipes qui gagneront avec l'IA seront celles qui gagnaient déjà sans elle — et les équipes qui sont cassées aujourd'hui le seront plus vite, plus cher, et devant plus de clients.