IA et développement : ce que les chiffres cachent vraiment

Quand un produit codé à l'arrache — pardon, vibe-coded — se revend 80 millions de dollars à Wix six mois après son lancement, on a envie de crier au miracle. Le problème ? La réalité est bien plus nuancée. Et surtout, bien plus instructive pour ceux qui veulent vraiment aller vite sanstout reconstruire dans la douleur.

Les outils IA sont un gain net sur un type de travail précis, et un coût net sur un autre. Les équipes qui ont compris cette différence sont celles qui livrent réellement plus vite — sans accumulateur de dette technique en prime.

Le problème de la sensation

Une étude récente de METR a demandé à des développeurs expérimentés de résoudre de vrais bugs dans leurs propres bases de code. Le protocole : estimation avant, puis après le travail, avec comparaison aux temps réels.

Résultat : les participants pensaient aller 24% plus vite avec l'IA. À la fin, ils se sont corrigés à 20% plus vite. Les mesures objectives ont montré qu'ils étaient en fait 19% plus lents.

Ce décalage entre ressenti et réalité, c'est le finding le plus important de toute la recherche sur le sujet. L'IA accélère la phase de frappe. Elle ralentit la phase de relecture. Et comme par hasard, les humains ne remarquent jamais le coût de la relecture — parce que ça ressemble terriblement à leur travail habituel.

Les 15 minutes gagnées sur le scaffolding ? Ça se voit. Les 25 minutes passées à débugger un code « presque correct » ? Ben non. C'est le job, quoi.

Là où le gain est réel

Le consensus scientifique pointe vers une catégorie bien précise : le code nouveau dans un territoire inconnu.

• Chez GitHub, un test contrôlé a montré une construction de serveur web 55% plus rapide avec Copilot.
• Plusieurs expériences terrain ont mesuré 26% de tâches en plus accomplies.
• Les développeurs juniors ont gagné 27 à 39% de productivité sur des missions courtes.

C'est exactement le profil d'un MVP. Un projet vierge, une stack qu'on découvre, du boilerplate qui se répète, ou une feature qu'on peut résumer en trois lignes de prompt. Sur ce terrain, les outils tiennent leurs promesses.

Le piège, c'est de croire que c'est ça le développement logiciel.

Là où ça freine

Le ralentissement mesuré par METR s'est produit pile où on l'attendait : des développeurs expérimentés qui maintenaient du code qu'ils avaient écrit eux-mêmes depuis des années. Le modèle générait du code qui avait l'air crédible pour un système qu'il ne comprenait pas. Le développeur passait du temps à vérifier si c'était juste. Et ce temps de vérification dépassait celui d'écrire la fonction lui-même.

À l'échelle d'une équipe, c'est là que ça dérape. Imagine le scénario classique :

1. Une startup s'appuie à fond sur l'IA pour expédier son MVP.
2. Elle trouve son product-market fit, commence à grandir.
3. Trois mois plus tard, elle découvre que le « code qui marche » contient :
   • Des vérifications de sécurité au niveau des lignes de base de données… commentées.
   • Un panel admin accessible à n'importe quel utilisateur authentifié.
   • Des clés API tranquillement placées dans le bundle côté client.

L'IA a écrit vite. L'IA a aussi introduit une revue de sécurité que personne n'a planifiée.

L'étude de Faros AI, menée sur plus de 10 000 développeurs en conditions réelles, a montré que l'IA ralentissait les équipes dans 20 à 40% des scénarios — surtout sur des codebases de plus de 100 000 lignes, là où la fenêtre de contexte ne peut simplement pas contenir l'ensemble du picture.

C'est le problème du brownfield. Et c'est là que bossent la plupart des équipes établies, la majeure partie du temps.

La facture sécurité que personne ne cite

Chaque semaine, son histoire : une startup dont le code généré par IA a exposé des données utilisateurs, un déploiement assistée IA qui a laissé un port de base de données grand ouvert, une injection de prompt qui a traversé jusqu'en production.

Ce ne sont pas des cas exotiques. Ce sont des sorties prévisibles d'un outil optimisé pour produire du code plausible, appliqué à du travail sensible sans regard de sécurité.

Le pattern est toujours le même. Les outils IA sont entraînés sur du code publiquement disponible. Ce code contient beaucoup de failles connues, de permissions mal configurées, de secrets codés en dur. Quand tu demandes à l'un de ces outils de te construire un système d'authentification ou une intégration de paiement, tu obtiens souvent une version qui ressemble à ce que ça devrait être. Pas forcément une version sécurisée.

Pour une startup qui bouge vite, c'est le risque critique. Tu ne construis pas juste un MVP. Tu construis une réputation et une surface de conformité. Une fuite de données dans ta première année ? Ce n'est pas un problème technique. C'est un problème de survie.

Le cadre pratique

La recherche donne une feuille de route assez claire.

Utilise l'IA sans retenue sur le greenfield. Nouveaux projets, prototypes, scaffolding, stacks inconnues, features bien délimitées — c'est là que le gain est réel et important. C'est aussi ce qui fait démarrer un MVP. C'est là que l'outil justifie son abonnement.

Utilise l'IA avec discernement sur le brownfield. Dans une codebase que tu connais bien, ou sur tout ce qui touche à l'authentification, aux paiements, aux données utilisateurs : traite la sortie IA comme un premier jet qui nécessite une revue sécurité. Le temps que tu budgettes pour cette revue, c'est le vrai coût de l'outil sur ce travail. Ne te laisse pas berner par la sensation de vitesse pour la zapper.

Livre petit, avec des tests. L'instabilité des sorties IA se manifeste surtout sur les gros changements complexes. Les petites modifications incrémentales avec une vraie couverture de tests captent les erreurs subtiles qui passent la relecture et causent des incidents en production. C'est une bonne pratique en général, mais ça devient critique quand l'IA est dans la boucle.

Durcit avant que les utilisateurs n'y touchent. Active les vérifications de sécurité row-level. Retire les secrets du code côté client. Ne pointe pas un agent IA vers une base de données de production. Ce ne sont pas des mesures exotiques — c'est le minimum vital pour tout système qui traite de vraies données utilisateurs. L'IA ne change pas ce minimum. Elle rend juste plus facile de le louper.

En résumé

Les outils IA de développement sont genuinely useful. Ils introduisent aussi des coûts qui sont réels, prévisibles, et presque jamais mentionnés dans les argumentaires commerciaux.

Les équipes qui livrent le plus vite ne sont pas celles qui utilisent l'IA pour tout. Ce sont celles qui l'utilisent stratégiquement — là où le gain de vitesse est réel — tout en protégeant les zones où la correctionprime sur la vélocité.

Si tu construis un MVP sur Vibe Hosting, sers-toi des outils IA pour avancer vite sur les pièces qui peuvent bouger. Utilise-les avec précaution sur les pièces qui doivent être justes.

Et si tu ne sais pas distinguer les deux… c'est probablement ta prochaine question à creuser.