Depuis que les outils IA ont commencé à générer du code potable, la peur dans le milieu c'était toujours la même : un jour, quelqu'un sans formation technique va écrire un truc avec Claude ou Copilot et vouloir le mettre en prod. On visualisait plutôt ça comme une vague lente, un freelance qui se prend pour dev, un entrepreneur qui veut se passer de prestataire. On pensait avoir le temps.
Ce qu'on n'avait pas anticipé, c'est que ça viendrait de l'intérieur.
Ce qui s'est passé
Dans mon entourage dev, ça s'est produit il y a peu. Un responsable hiérarchique, armé de Claude et d'une bonne dose de confiance, a soumis du code à son équipe avec une demande simple : on le met en prod. L'équipe a refusé. Le code avait des problèmes évidents, des appels API mal configurés, des variables d'environnement codées en dur, le genre de truc qu'on voit quand quelqu'un n'a jamais eu à déployer quoi que ce soit pour de vrai.
Le manager a insisté. Plusieurs fois. En réunion. Par écrit. Jusqu'à ce que la pression soit suffisante pour que la question ne soit plus "est-ce qu'on le déploie" mais "est-ce qu'on le répare d'abord ou on le laisse partir tel quel".
C'est là que ça devient intéressant.
Le dilemme de la baby-sitter
Tu as deux options.
Première option : tu déploies le code tel quel. Il plante, la preuve est dans les logs, tout le monde voit que c'était une mauvaise idée. Sauf que tu viens de mettre en prod quelque chose de cassé sciemment, et c'est toi qui vas gérer les retombées.
Deuxième option : tu passes du temps à reprendre, corriger, tester du code que tu n'as pas écrit, pour une décision que tu as refusée. Tu es maintenant la baby-sitter de la mauvaise idée de quelqu'un d'autre. Et le message implicite que tu envoies, c'est que c'est acceptable de fonctionner comme ça.
Les deux options sont mauvaises. Et c'est exactement pour ça que ce sujet revient en boucle sur Reddit. Ce thread sur r/NoStupidQuestions posait la question directement, et les réponses montraient que c'est pas un cas isolé. C'est systémique.
Pourquoi ça casse quelque chose de plus profond
Le problème n'est pas technique. Enfin si, mais c'est pas là qu'il commence.
Dans une boîte qui fonctionne, chacun a un rôle en rapport avec ses compétences et ce qu'on attend de lui. Un dev qui code, c'est normal, c'est son boulot. Un dirigeant qui code et qui pousse ça en prod par-dessus l'avis de son équipe technique, c'est un problème de gouvernance. Le fait que l'outil utilisé soit Claude ou n'importe quel autre LLM ne change rien à ça.
Ce que ça révèle, c'est que certains managers ont vu dans l'IA une façon de contourner la dépendance à l'équipe tech. Le problème c'est que coder c'est pas juste écrire des lignes qui s'exécutent. C'est savoir pourquoi elles s'exécutent, dans quel contexte, avec quelles contraintes, et ce qui se passe quand elles ne s'exécutent plus. Le localhost:3000 qui traîne dans les variables d'env, l'API key hardcodée dans le fichier de config, le service tiers qui nécessite un abonnement payant non déclaré : c'est exactement ce qu'on retrouve dans ces codes générés à la va-vite et poussés avec conviction.
Et la valeur des devs là-dedans
Honnêtement, je n'ai pas de réponse propre.
Ce que je sais, c'est que ce qui s'est passé dans cette équipe n'est pas un problème d'IA. C'est un problème de décision prise sans les compétences pour en mesurer les conséquences. L'IA a juste rendu ce problème plus accessible, plus fréquent, et plus difficile à refuser poliment.
La vraie question que ça pose : est-ce que la valeur d'un dev devient de plus en plus celle de quelqu'un qui valide, corrige et assume les erreurs des autres, ou est-ce qu'elle reste dans la capacité à construire quelque chose de cohérent de bout en bout ?
Et vous, vous feriez quoi ?