Cinq signaux qui prouvent que c'est l'AI qui est aux commandes
On a toutes et tous prompté un matin et fini la journée sans savoir ce qu'on avait livré. La CI est verte. Slack est calme. Et pourtant une petite voix dit *"je ne sais pas exactement ce que ce bout de code fait"*. Bienvenue dans le vibe coding, version équipe.
Je ne vais pas redéfinir le terme : Lucas Macori l'a déjà fait sur sfeir.dev, avec ses trois dangers. Je pars du principe que tu en as fait l'expérience. Cet article s'adresse aux développeurs et tech leads en équipe qui utilisent déjà l'IA pour coder et qui commencent à sentir que le projet dérive.
Si tu codes en solo sur un side-project, les quatre premiers signaux restent valables ; saute le cinquième. Si tu as déjà un `CLAUDE.md` partagé et une grille d'acceptation dans ton équipe, saute directement à la dernière partie : tu as fait le plus dur.
Ce diagnostic, je le tire d'un an de pilotage sur RAISE, la plateforme GenAI de SFEIR déployée chez des dizaines de clients, avec une trentaine de contributions mergées par semaine, dont une part importante est passée par Claude Code ou équivalent.
J'ai vu passer assez de PRs vibe-codées pour en reconnaître les symptômes les yeux fermés — parce que c'est d'abord sur les miennes que je les ai vus. Voici les 5 red flags, dans l'ordre où ils apparaissent dans un projet :
1. L'IA résout le ticket, plus personne ne tient le cadre
2. Sans convention écrite, la qualité du projet dérive
3. Le test le plus dangereux est celui qui passe
4. Les métriques au vert, mais l'équipe freine
5. Un module que personne ne comprend est une régression qui s'ignore
Red flag #1 — L'IA résout le ticket, plus personne ne tient le cadre
La PR résout une demande, mais elle ne s'inscrit plus dans l'intention plus large du produit. Le ticket disait : "ajouter un champ optionnel `invoice_reference` sur le formulaire de commande". La PR fait ça, et en profite aussi pour : migrer la base, ajouter un endpoint dédié, refactorer le contrôleur de commande "parce que c'était sale".
Résultat : 600 lignes de diff pour ce qui aurait dû en faire 30. Aucune de ces additions n'est *mauvaise*. Toutes sont hors-sujet. L'IA a suivi la pente de la généralisation pendant que personne ne tenait le cadre.
Le cas le plus franc que j'ai vu passer sur RAISE : un ticket "change la couleur du badge de notification". PR associée : +6 000 / −7 000 lignes sur onze fichiers, incluant localisation du module, limite par défaut du nombre de notifications affichées, et les bases d'un futur revamp. Chaque idée était défendable. Aucune n'était dans le ticket.
Quand tu revois ce type de PR, une seule question à te poser : *"Si j'avais codé ça à la main, j'aurais touché à ces fichiers ?"* Si la réponse est non, tu as ton signal.
Red flag #2 — Sans convention écrite, la qualité du projet dérive
Dans la même branche : trois façons différentes de lire un fichier de configuration. Deux conventions de nommage pour des variables d'environnement qui parlent de la même chose. Deux styles de gestion d'erreur qui cohabitent dans le même module.
Sur RAISE, le signal le plus net est venu d'une PR de janvier 2026 titrée "refacto: only 1 notification system" — 98 fichiers touchés. Le titre est l'aveu : only 1 admet, en creux, qu'il y en avait plusieurs. Aucun de ces systèmes n'était mauvais. Aucun n'était cohérent avec les autres.
Une IA ne choisit pas un style : elle prend ce qu'elle voit dans le contexte et continue dans la même direction. Si le repo n'a pas de convention écrite et citable — dans un `CLAUDE.md`, un `AGENTS.md`, un `CONTRIBUTING.md` — chaque PR vote pour un style différent.
C'est mécanique, ce n'est pas malveillant, et ça ne change rien au problème : six mois plus tard, un nouveau dev arrive, demande "c'est laquelle des trois, la bonne manière ?", et personne ne sait répondre.
Red flag #3 — Le test le plus dangereux est celui qui passe
Les tests passent. La feature ne marche pas. Comment ?
Parce que l'IA a écrit un test qui mocke exactement le comportement qu'elle a codé, au lieu de vérifier le comportement attendu. Ça ressemble à un test. Ça passe en CI. Ça n'a aucune valeur.
La première fois que j'ai vu ça sur RAISE, j'ai pensé "c'est un stagiaire qui a fait ça". C'était moi, trois semaines plus tôt, en vibe-codant un vendredi soir : l'IA m'avait sorti une suite de tests impeccable, j'avais lu le nom des tests, pas leur contenu.
Le cas le plus caricatural est arrivé plus tard, dans une PR de remise en état — 24 tests défaillants réparés, mocks désalignés de la vraie structure de réponse de l'API depuis des semaines. Aucun n'avait fait tomber la CI : ils ne testaient rien.
Depuis, je lis chaque assertion. Pas chaque ligne — chaque `assert`, chaque `expect`. Cinq minutes par PR, non négociables.
Red flag #4 — Les métriques au vert, mais l'équipe freine
Le lint passe. La CI est verte. Coverage, complexité cyclomatique, duplication : stables ou en amélioration. Et pourtant ton équipe prend 40 % de temps en plus pour livrer une feature équivalente à celle du trimestre dernier.
Les métriques ne disent pas "on rame", elles disent "tout va bien".
Le signal est ailleurs : dans la durée des standups, dans les "c'est où dans le code que…", dans les "ah, je pensais que c'était géré par l'autre module". Ce sont des micro-pertes de 15 secondes par conversation, et tu en paies une centaine par semaine.
Le déclic sur RAISE est venu d'une issue ouverte par un dev : "Refactor: split `dependencies.py` into multiple modules". Un fichier unique de plusieurs milliers de lignes grossi feature après feature, devenu intraversable. Le lint était content, le coverage bon — mais plus personne n'y entrait. Quand une équipe se met à contourner un fichier plutôt qu'à l'ouvrir, ce fichier est déjà mort, même si le linter sourit.
Si ton ressenti d'équipe dit "on rame" alors que les métriques disent "tout va bien" — écoute ton équipe.
Red flag #5 — Un module que personne ne comprend est une régression qui s'ignore
Un dossier, une poignée de classes que l'IA a produits en réponse à une demande précise il y a trois mois. Aujourd'hui, tu demandes à trois devs à quoi ça sert. Tu obtiens trois réponses, toutes partielles, aucune certaine.
Cas vécu récemment sur RAISE : un audit de permissions a révélé plus de 27 permissions obsolètes en base, certaines ciblées par des migrations pour des noms qui n'existaient déjà plus dans le code. Chacune avait été ajoutée pour une raison précise, puis oubliée. Les devs interrogés sur une permission prise au hasard : des hypothèses, mais aucune certitude.
Ma règle : si trois devs ne savent pas à quoi sert un module que l'IA a écrit, il faut soit le documenter, soit le supprimer — jamais le maintenir tel quel. Garder vivant un module que personne ne comprend, c'est espérer que la prochaine régression sera mineure. Protip: elle ne le sera pas.
Soyons honnêtes : ces cinq symptômes existaient avant l'IA. Les PRs de 600 lignes, les tests qui se mockent eux-mêmes, les modules orphelins, on en voyait déjà en 2003. Ce qui a changé, c'est la vitesse à laquelle ça s'accumule. Le problème n'est pas l'outil, mais l'usage qu'on en fait.
Ton auto-diagnostic immédiat
Une question par red flag, chacune en moins de 15 minutes :
1. Cadre produit — prends les dernières PRs mergées produites par l'IA. Pour chacune, le diff est-il proportionné au ticket ?
2. Convention écrite — dans les 50 derniers fichiers modifiés, y a-t-il plus d'une façon de faire la même chose technique ?
3. Tests utiles — sur 1 PR au hasard, lis les tests liés. Vérifient-ils un comportement attendu, ou décrivent-ils simplement ce que le code fait ?
4. Carte mentale — demande à ton équipe "qu'est-ce qui nous ralentit ?" sans montrer aucune métrique. Compare ensuite les réponses aux métriques de suivi du projet.
5. Modules orphelins — liste les 3 dossiers les moins touchés du projet ces derniers mois. Sans IA, saurais-tu expliquer à quoi ils servent ?
---
Et chez toi, lequel des cinq signaux est apparu en premier ?
Celui-là t'indique par où commencer — et c'est précisément le sujet de l'épisode 2 à venir : "Cadrer avant de prompter : la méthode que j'utilise pour merger 30 PRs par semaine".
Conclusion
Le vibe coding ne crée pas de nouveaux problèmes : il accélère ceux qu’on connaissait déjà. L’IA produit vite. À toi de tenir le cadre.
Sans intention claire, elle optimise localement et désorganise globalement. Les équipes qui s’en sortiront ne seront pas les plus rapides, mais les plus lucides : celles qui savent quand faire confiance à l’IA… et quand reprendre la main.
Hamadi JABLOUN
Charlotte Ryssen (Coumont)
