Un résultat annoncé vaut-il une validation ?
Non, et confondre les deux coûte cher. Un outil qui affiche « terminé » signale qu’il a exécuté une suite d’actions. Il ne dit rien sur ce que ces actions ont produit.
Un agent qui modifie un logiciel peut livrer un programme qui démarre sans erreur tout en cassant un cas particulier, par exemple la commande d’un client qui paie en deux fois. Personne ne le voit au moment de la livraison, tout le monde le voit quand le client appelle.
Cognition, l’entreprise qui édite l’agent logiciel Devin, a montré un cas très concret. L’agent teste un jeu pour iPhone, rend une vidéo du jeu qui tourne dans un simulateur et joint un rapport qui liste les vérifications réussies et les zones restées non testées. La vidéo montre le comportement réel de l’application, le rapport montre l’étendue des tests. Un seul des deux ne suffirait pas.
Comment obtenir une preuve du travail d’une IA ?
Demandez une trace, pas une phrase. Trois supports couvrent la plupart des besoins : le journal d’exécution, le rapport de contrôles, la capture du résultat.
Le journal indique ce qui a été lancé et à quel moment. Le rapport indique ce qui a été testé, ce qui a réussi et ce qui n’a pas été couvert. La capture montre l’état final, l’écran obtenu après une correction par exemple.
L’exemple le plus parlant reste celui du bug signalé par un client. Le client envoie une capture d’écran, l’équipe la transmet à l’agent, l’agent corrige et renvoie une capture du résultat. La boucle se referme sur une image vérifiable.
À Auxerre, cela ne change qu’une chose au quotidien : au moment de valider, vous regardez une pièce, pas une déclaration.
Où garder un humain dans la boucle ?
Là où l’argent et la relation client sont engagés. Partout ailleurs, l’automatisation peut travailler seule.
La liste est courte et elle tient sur un post-it :
- un devis ou un email envoyé à un prospect
- une facture émise ou un prélèvement déclenché
- une publication visible sur les réseaux
- une modification d’une page que vos visiteurs consultent
Sur ces quatre points, une relecture humaine rapide évite une reprise de plusieurs heures. Le reste, le classement des messages, la mise à jour d’un tableau de suivi, la préparation d’un brouillon, se passe très bien de validation immédiate.
Faut-il tester avant de brancher en vrai ?
Oui, sur deux familles de cas au minimum : les cas normaux et les cas limites. Un test qui ne couvre que le cas normal ne teste rien.
Les cas normaux sont ceux que vous traitez tous les jours, un client qui commande une prestation, un message reçu dans la boîte contact. Les cas limites sont ceux qui arrivent rarement et font mal : un nom avec une apostrophe, un montant à zéro, une pièce jointe trop lourde, une demande en double.
Perplexity confie à GPT-6 Astra la rédaction de communications, la modification de logiciels et la surveillance de systèmes en production. Son cofondateur explique demander au modèle de construire un petit programme de test qui simule les services voisins, afin de vérifier le parcours de bout en bout. Autrement dit, l’IA écrit elle-même son banc d’essai avant d’agir.
Pour une TPE, la version réaliste tient en une demi-journée par automatisation : faites tourner l’outil sur plusieurs dossiers réels, dont les deux plus compliqués, et comparez le résultat à ce que vous auriez fait à la main.
Exiger des preuves ralentit-il le travail ?
Non, cela déplace le temps au lieu de l’ajouter. Le temps passé à relire chaque étape baisse au profit du temps passé à contrôler les points sensibles.
Walden Yan, cofondateur de Cognition, explique que cette capacité de l’IA à tester et à prouver que son travail fonctionne comme prévu est ce qui progresse le plus. Son objectif est clair : moins relire le code à la main et livrer davantage. La même mécanique s’applique à une petite structure. Quand l’automatisation documente ce qu’elle a vérifié, vous arrêtez de douter en permanence et vous ne regardez plus que ce qui compte.
Perplexity fonctionne aujourd’hui avec beaucoup moins de points de contrôle que sur les modèles précédents, précisément parce que le modèle prouve son parcours. La confiance ne vient pas d’un discours, elle vient d’un rapport que vous pouvez ouvrir.
En résumé
Une automatisation fiable ne se juge pas à ce qu’elle annonce mais à ce qu’elle montre. Exigez une trace, journal, rapport ou capture. Gardez un humain sur les étapes qui engagent de l’argent ou un client, testez les cas limites avant la mise en service, et laissez tourner le reste. Bien encadrée, une automatisation fait gagner du temps. Non vérifiée, elle fait perdre la confiance.