Le vibe coding a changé les personnes capables de produire une application qui semble fonctionnelle. Un prompt peut générer des écrans, connecter une API et assembler un flux de travail plausible avant même qu’une équipe d’ingénierie traditionnelle ait terminé sa première revue de conception.

Cette rapidité crée un nouveau problème de recrutement et de livraison : une démo ne constitue plus une preuve solide que le logiciel est de qualité. Les employeurs poseront de plus en plus une question plus difficile : ce système construit par une IA peut-il se comporter correctement lorsque les entrées sont désordonnées, que les dépendances échouent, que les utilisateurs répètent des actions et que le modèle sous-jacent change ?

La réponse viendra d’un niveau d’exigence en matière de qualité qui ressemblera moins à du polish visuel qu’à une vérification logicielle rigoureuse. Les personnes qui se démarqueront ne montreront pas simplement ce qu’un outil de programmation par IA a produit. Elles montreront comment elles l’ont testé, ce qu’il ne peut pas faire en toute sécurité et comment elles savent qu’une modification n’a rien cassé ailleurs.

Un benchmark est une preuve, pas un score de classement

Les benchmarks open source d’agents de programmation offrent des points de départ utiles, mais ils mesurent des aptitudes différentes. SWE-bench utilise de véritables problèmes GitHub et des instantanés de dépôts, ce qui le rend pertinent pour les travaux de maintenance. Terminal-Bench évalue les interactions en ligne de commande. D’autres benchmarks répertoriés, notamment SlopCodeBench et ProgramBench, ciblent différents aspects du code généré et du comportement des agents.

Ces benchmarks peuvent aider à comparer des outils ou à établir une référence, mais les employeurs devraient éviter de considérer un score unique comme une preuve de préparation à la mise en production. Un modèle qui résout des problèmes de dépôt peut tout de même produire une logique d’autorisation dangereuse. Un agent qui accomplit des tâches dans un terminal peut échouer à préserver l’état au cours d’un long flux de travail. Une application web soignée peut réussir une démo correspondant au parcours nominal tout en gérant mal les nouvelles tentatives ou les paiements en double.

Un portfolio crédible ou une revue interne devrait donc inclure un ensemble d’évaluation propre à la tâche. Cet ensemble pourrait contenir des rapports de bugs représentatifs, des parcours utilisateur normaux, des entrées malformées, des limites de permissions, des défaillances de dépendances et des régressions précédemment corrigées. Chaque cas devrait avoir un résultat attendu explicite, et pas seulement une capture d’écran qui semble correcte.

Le pack de tests minimal pour les logiciels construits par une IA

Pour une petite application, il est possible de constituer un pack qualité utile sans laboratoire de recherche sophistiqué :

  • Tests d’acceptation : vérifier le comportement visible par l’utilisateur pour les flux de travail les plus importants, y compris les résultats positifs et négatifs.
  • Tests unitaires et d’intégration : vérifier les règles métier de manière isolée et confirmer que les bases de données, les API, les files d’attente et l’authentification fonctionnent ensemble comme prévu.
  • Tests négatifs : envoyer des entrées manquantes, malformées, surdimensionnées, dupliquées et non autorisées. Le code généré par une IA est souvent particulièrement convaincant sur le parcours montré dans le prompt ; les parcours non demandés sont donc importants.
  • Tests de régression : transformer chaque défaut découvert en test permanent. Une démo au vert après une correction ne suffit pas si le même échec peut réapparaître dans la prochaine modification générée.
  • Contrôles de sécurité : tester le contrôle des accès, la gestion des secrets, les défenses contre les injections, les vulnérabilités des dépendances et la possibilité pour du contenu non fiable d’influencer des appels d’outils ou des actions privilégiées.
  • Contrôles opérationnels : vérifier les délais d’expiration, les nouvelles tentatives, l’idempotence, la journalisation, les alertes et le comportement sûr lorsqu’une dépendance est indisponible.

Cela correspond largement à l’état d’esprit d’ingénierie qualité décrit dans le récit de Stack Overflow consacré au cycle de vie agentique du développement logiciel. Le changement important est culturel : l’assurance qualité n’est pas une inspection finale après qu’une IA a écrit le code. C’est la structure qui rend la génération rapide suffisamment sûre pour être utilisée.

Tester l’orchestration, pas seulement le résultat

Lorsqu’un logiciel comprend un agent d’IA, les tests classiques de l’application sont nécessaires, mais insuffisants. Le système peut échouer parce que le modèle a mal compris une demande, mais aussi parce que l’orchestration environnante a perdu le contexte, appelé deux fois un outil, accepté une sortie structurée malformée ou ne s’est jamais arrêtée.

Les domaines de régression avant déploiement recommandés par le digest constituent une liste de contrôle pratique : perte de contexte, idempotence des outils, injection de prompt, sortie structurée, non-terminaison, ancrage de la recherche documentaire et réhydratation de l’état. Ce sont des propriétés d’ingénierie que l’on peut tester.

Par exemple, un test peut exécuter deux fois la même demande et confirmer que la seconde tentative ne crée pas une commande en double. Un autre peut interrompre un agent au milieu d’un flux de travail, le redémarrer et vérifier qu’il reprend depuis un état valide au lieu de répéter une action irréversible. Un test de recherche documentaire peut exiger du système qu’il ne cite ou ne renvoie que des informations provenant d’un ensemble de sources approuvées. Un test de sortie structurée peut fournir une réponse invalide et confirmer que l’application la rejette correctement au lieu de la traiter silencieusement comme des données valides.

Les systèmes de longue durée et multi-agents ont particulièrement besoin de comptes rendus d’échec clairs. Des chercheurs travaillent sur l’attribution automatisée des échecs, car il peut être difficile d’identifier quel agent a provoqué un échec et à quel moment d’une longue chaîne d’interactions. En pratique, les équipes devraient conserver les appels d’outils, les entrées, les sorties, les versions des modèles, les horodatages, les transitions d’état et les décisions finales dans une piste d’audit respectueuse de la vie privée. Sans ces éléments, un test rouge vous indique que quelque chose a échoué, mais pas par où commencer pour le corriger.

La reproductibilité deviendra un avantage professionnel

Le code généré par une IA est variable. Une nouvelle exécution peut produire une implémentation différente ; une mise à jour du modèle peut modifier le comportement ; une panne du fournisseur peut changer le routage ou la latence. Les employeurs accorderont donc de la valeur aux candidats capables de rendre les évaluations reproductibles.

Cela signifie qu’il faut, lorsque c’est possible, figer les instantanés des modèles, enregistrer les prompts et la configuration, contrôler l’aléatoire lorsque la plateforme l’autorise et effectuer plusieurs essais pour les tâches dont les résultats varient. Le digest souligne notamment l’utilité des instantanés figés, d’une température faible ou nulle lorsque cela est possible et de barrières CI/CD assorties de seuils de confiance.

Un rapport pratique devrait distinguer au moins trois résultats :

  1. Taux de réussite : nombre de cas réussis.
  2. Cohérence : fréquence à laquelle un même cas réussit lors d’exécutions répétées.
  3. Gravité : détermination de la nature des échecs : cosmétique, gênante, dommageable pour les données, liée à la sécurité ou susceptible d’entraîner une action externe dangereuse.

Un système qui réussit 19 contrôles de formatage à faible risque sur 20 n’est pas nécessairement meilleur qu’un autre qui réussit 18 cas sur 20, mais ne franchit jamais une limite d’autorisation. Le niveau de qualité exigé doit pondérer les échecs en fonction de leurs conséquences.

La revue humaine doit cibler les risques, pas chaque ligne

L’objectif d’une meilleure automatisation n’est pas de contraindre une personne à relire chaque jeton produit par une IA. Il est d’orienter l’attention humaine vers les décisions que les tests ne peuvent pas trancher entièrement.

Les réviseurs doivent se concentrer sur l’authentification et l’autorisation, la conservation des données, les actions financières ou contractuelles, la confidentialité, les migrations, la récupération après erreur, les autorisations accordées à des tiers et les modifications qui affectent le propre système d’évaluation du système. Pour un agent, ils doivent également vérifier quels outils il peut appeler, à quelles données chaque outil peut accéder et si une approbation est requise avant toute action irréversible.

Les différences visibles, les flux d’approbation, les conversations archivées et les journaux d’audit — des fonctionnalités mises en avant dans la description de Slack Code consacrée au codage collaboratif par IA — indiquent une attente plus large : l’historique de la création d’un logiciel aura de l’importance. Un réviseur doit pouvoir comprendre la demande, examiner la modification générée, voir les éléments probants issus des tests et identifier la personne qui a approuvé le déploiement.

Ce relevé n’est pas de la bureaucratie pour elle-même. Il permet de distinguer une démonstration impressionnante d’une modification contrôlée qu’une autre personne peut maintenir.

Que présenter dans un portfolio ou lors d’un entretien

Pour les candidats, la démonstration la plus convaincante est un petit système dont la démarche qualité est délibérément visible. Incluez le dépôt, les instructions d’installation, les notes d’architecture, les commandes de test, des cas de test représentatifs, les limitations connues et un bref rapport d’échec. Montrez un ou deux bogues qui ont été trouvés et transformés en tests de régression. Expliquez quel modèle ou agent de codage a été utilisé, sans présenter l’outil comme l’auteur des décisions d’ingénierie.

Si l’application utilise un agent, documentez les autorisations des outils, le modèle d’état, la politique de nouvelle tentative, la condition d’arrêt et les étapes nécessitant une approbation humaine. Si elle utilise la récupération d’informations, montrez comment les sources sont sélectionnées et ce qui se passe lorsque les éléments probants sont absents. Si elle appelle des services externes, démontrez le comportement en cas d’expiration du délai et de demande en double.

Ne revendiquez pas la fiabilité à partir d’un seul enregistrement réussi. Une affirmation vérifiable ressemblerait davantage à ceci : « Sur 30 exécutions enregistrées de ces 12 scénarios, le système a satisfait aux critères d’acceptation dans 28 cas ; les deux échecs concernaient une saisie de date ambiguë et sont tous deux documentés. » Le nombre en lui-même est moins important que la méthode, les limites et l’honnêteté quant à ce qui reste non testé.

La nouvelle définition de la rapidité

L’IA réduit le coût de production d’une première version. Elle ne supprime pas le coût nécessaire pour déterminer si cette version mérite confiance. En fait, une génération plus rapide peut rendre l’évaluation plus importante, car davantage de modifications non révisées peuvent s’accumuler entre les déploiements.

Le professionnel de l’après-codage instinctif sera évalué sur la boucle suivante : définir le comportement, générer ou modifier le code, tester des cas réalistes et adverses, examiner les décisions à haut risque, consigner les échecs et améliorer le système sans perdre les éléments probants. Les bancs d’essai peuvent aider à comparer les capacités. Les pratiques d’assurance qualité déterminent si ces capacités se transforment en logiciels fiables.

Le niveau de qualité exigé n’est donc pas : « Pouvez-vous créer une application avec l’IA ? » Il est plutôt : « Pouvez-vous démontrer ce que fait l’application, détecter quand elle cesse de le faire et concevoir les limites qui empêchent un échec de devenir un incident ? »