Dev informatique assisté par l'IA, mais à quel prix ?

Tout le monde a un avis sur l'IA dans le dev. Les enthousiastes qui voient une révolution, les sceptiques qui refusent d'y toucher.

Moi je suis quelque part au milieu — j'utilise ces outils, j'en tire des choses, et j'en suis aussi revenu sur certaines illusions.

Le jour où j'ai failli shipper du code cassé

Il y a quelques jours, je travaillais sur une feature assez classique — gestion de tokens d'authentification avec refresh automatique. J'avais demandé à Claude (Sonnet 4.6) de générer la logique de rotation. Le code rendu était propre. Vraiment propre. Nommage cohérent, gestion des cas d'erreur apparente, structure claire.

Je l'ai relu en diagonale. Ça semblait correct.

C'est en écrivant les tests d'intégration que j'ai vu le problème : dans un scénario de requêtes concurrentes, la logique de refresh pouvait être déclenchée deux fois simultanément, invalidant le premier token pendant que le second était encore en vol. Race condition classique. Le genre de bug qui n'apparaît jamais en dev, jamais en staging, et qui explose en prod un vendredi soir.

L'IA n'avait pas halluciné une API inexistante. Elle n'avait pas fait une erreur de syntaxe. Elle avait produit du code fonctionnel dans 95% des cas, et silencieusement faux dans les 5% restants. C'est ça le vrai piège.

Ce que l'IA fait bien — et pourquoi c'est quand même utile

Je ne veux pas tomber dans l'autre extrême non plus. Sur des tâches précises et bien délimitées, le gain est réel.

La génération de boilerplate, les conversions de types, les tests unitaires sur des fonctions pures, la documentation — tout ça sort vite et correct. Quand je sais exactement ce que je veux et que c'est du code "connu" (bien représenté dans les données d'entraînement), l'IA me fait gagner du temps sans m'exposer à grand chose.

Le problème c'est que cette expérience positive crée une confiance progressive. Et cette confiance, elle déborde. On commence à l'utiliser sur des cas plus complexes, plus critiques, avec le même niveau de relecture. C'est là que ça dérape.

La dette qu'on ne voit pas venir

Il y a un phénomène que j'observe chez des collègues qui l'utilisent beaucoup plus que moi : le codebase commence à ressembler à un patchwork. Chaque module a été généré avec un contexte différent, des conventions légèrement différentes, des choix d'implémentation qui ne se parlent pas vraiment entre eux. Ça fonctionne. Mais personne ne le maîtrise vraiment de bout en bout.

Le LLM travaille dans sa fenêtre de contexte. Il ne connaît pas votre architecture globale, vos décisions passées, les contraintes spécifiques à votre projet. Chaque génération est localement cohérente et globalement orpheline. Sur un petit projet solo c'est gérable. Sur un projet d'équipe qui dure, c'est une bombe à retardement.

Et le truc sournois, c'est que la dette s'accumule sans signal d'alarme. Le code tourne, les tests passent, les PR sont validées. C'est seulement six mois plus tard, quand il faut faire évoluer un module, qu'on réalise que personne ne sait vraiment pourquoi il est structuré comme ça.

Ce que ça coûte vraiment

Financièrement, les abonnements aux outils sont dans la fourchette 15-40€ par mois par développeur. C'est négligeable. Le vrai coût n'est pas là.

Le coût cognitif, par contre, est sous-estimé. Chaque fois qu'on délègue un problème difficile à l'IA sans se battre avec lui d'abord, on passe à côté d'un apprentissage. À court terme c'est invisible. Sur deux ans, certains développeurs que je connais ont du mal à écrire des algorithmes non triviaux sans assistance. Le muscle s'atrophie faute d'usage. C'est pas dramatique, c'est juste réel.

Et puis il y a la question de la responsabilité. Quand un bug passe en prod sur du code généré par IA et relu trop vite — qui est responsable ? La réponse légale et éthique est claire : le développeur qui a validé. Mais en pratique, dans une équipe, le flou s'installe. Les process de revue n'ont pas encore été adaptés à cette réalité dans beaucoup de boîtes.

Comment j'essaie de m'en servir sans me faire avoir

Ma règle personnelle : l'IA accélère ce que je comprends déjà, elle ne remplace pas la compréhension.

Concrètement — je ne génère jamais un module entier sans avoir d'abord défini l'interface, les invariants, et les cas limites dans ma tête. Je traite chaque output comme une PR d'un dev externe compétent mais qui ne connaît pas mon projet. Je relis. Vraiment.

Et sur tout ce qui touche à la sécurité, à la concurrence, ou à de la logique métier critique — je code moi-même, ou au minimum je confronte l'output à une relecture très serrée avec les tests qui vont avec.

C'est plus lent que de faire confiance aveuglément. C'est exactement pour ça que ça marche.

L'IA dans le dev, c'est un outil puissant avec un défaut de conception fondamental : il est trop confortable pour être utilisé avec la vigilance qu'il requiert. Le prix à payer, c'est cette vigilance justement — maintenue précisément parce que tout semble facile.