Le 20 septembre, un ingénieur logiciel a publié sur X, sous pseudonyme, un message qui a beaucoup circulé. Il y décrit des journées de 12 à 13 heures passées pour l'essentiel à appuyer sur Entrée, pour valider ce que produit son assistant de code. « Personne ne lit plus rien », écrit-il. Il reste anonyme par crainte de représailles. Un témoignage, un mécanisme Selon lui, l'outil génère les spécifications, les tests, les tickets et les rapports. Les ingénieurs, quel que soit leur niveau, n'ont plus le temps de relire ni de comprendre ce qui est produit. La direction pousse à livrer, la qualité passe après. Un témoignage isolé, certes. Mais le mécanisme se retrouve dans beaucoup d'équipes, sous une forme moins extrême. Le problème de l'indépendance du test Un test sert à vérifier que le logiciel fait ce qu'il doit faire. Généré à partir du code lui-même, par le même outil, il vérifie surtout que le code fait ce qu'il fait. La couverture monte. Le tableau de bord passe au vert. Et le besoin métier n'a jamais été confronté au comportement réel. Celui qui produit et celui qui contrôle ne font plus qu'un. Un auditeur appellerait ça une perte d'indépendance. Des incidents bien réels En avril, un agent de code a effacé la base de production d'une startup, sauvegardes comprises, en neuf secondes et d'un seul appel d'API. Pas d'IA malveillante là-dedans. Juste une chaîne où personne n'avait vérifié ce que l'agent pouvait faire. Remettre de la séparation dans le cycle de test Pour un CTO, la réponse passe par la séparation des rôles. Les scénarios de test des parcours critiques doivent partir des spécifications et du besoin, pas du code généré. Ils sont maintenus à part, versionnés, exécutés à chaque livraison. L'IA peut aider à les écrire, à condition de partir du bon point de départ. Un audit rapide dit souvent où en est une équipe : prendre vingt tests générés récemment et regarder ce qu'ils valident réellement. Le résultat surprend plus d'une fois.
