Faire confiance, mais vérifier
L’IA se trompe avec assurance un certain pourcentage du temps. La compétence n’est pas de vérifier chaque ligne. C’est de savoir lesquelles vérifier.
Le résultat le plus dangereux est celui qui a l’air juste.
Pas l’erreur évidente, le build qui plante, la variable mal orthographiée. Celles-là sont faciles. Elles s’annoncent d’elles-mêmes. Le résultat dangereux est celui qui compile, passe un survol rapide, se lit avec fluidité, et fait la mauvaise chose. C’est la décision d’architecture qui semble raisonnable et qui introduit en douce une dépendance que nous regretterons dans six mois. C’est la prévision trimestrielle au formatage impeccable avec une hypothèse défaillante enfouie à la ligne 47.
C’est la dernière compétence de cette série, et ce n’est pas pour rien. L’évaluation est la compétence qui boucle la boucle. Sans elle, les cinq autres (spécification, jugement, décomposition, orchestration, intention) forment un pipeline qui produit des erreurs polies à grande échelle.
Le problème de l’assurance
Les hallucinations ne sont pas un problème de données d’entraînement. Même avec des données parfaites, les objectifs d’entraînement eux-mêmes produisent des erreurs. C’est structurel. Ce n’est pas un bogue qui sera corrigé dans la prochaine version. C’est une propriété du fonctionnement de ces systèmes.
Les analyses à grande échelle du code généré par l’IA trouvent invariablement le même motif : plus de problèmes de logique que dans le code écrit par des humains. Pas des erreurs de syntaxe. Des erreurs de logique : du code qui fait la mauvaise chose correctement. Il roule. Il passe les tests de base. Il ne fait simplement pas ce dont nous avions réellement besoin.
Le portrait organisationnel est le même : des taux de bogues en hausse corrélés à l’adoption de l’IA, accompagnés de temps de révision de code nettement plus longs. Nous livrons plus vite et révisons plus longtemps, parce que le résultat exige plus de vigilance, pas moins.
Le motif est constant. L’IA n’échoue pas bruyamment. Elle échoue discrètement, plausiblement, d’une manière qui passe une inspection distraite. Le mode de défaillance qui compte n’est pas la machine désobéissante. C’est la machine parfaitement obéissante qui exécute sans faute une spécification défaillante, puis présente le résultat avec l’assurance de quelqu’un qui n’a jamais douté de lui-même une seule fois.
Ce qu’est vraiment l’évaluation
L’évaluation, ce n’est pas lire chaque ligne. C’était déjà impraticable quand les humains écrivaient le code. Ça l’est certainement quand l’IA en produit dix fois plus.
L’évaluation est de la reconnaissance de motifs appliquée au résultat. C’est la compétence de savoir où se cachent les erreurs, à quoi ressemble le « assuré mais faux », et quelles parties d’un résultat méritent une attention soutenue plutôt qu’un survol.
Il y a des motifs précis qui valent la peine d’être appris. Les conditions aux limites sont là où l’IA trébuche le plus : les cas limites, les états vides, les scénarios « qu’arrive-t-il quand c’est zéro ». L’IA tend à bâtir pour le chemin heureux, parce que le chemin heureux domine les données d’entraînement. Les spécifications que nous écrivons (compétence 1) tendent à décrire ce qui devrait arriver, pas ce qui devrait arriver quand ça tourne mal.
Les contradictions dans les spécifications causent dès maintenant de vrais problèmes. À mesure que les modèles suivent les instructions avec plus d’acuité, ils prennent tout plus au pied de la lettre. Si notre spec dit « toujours répondre en moins de 200 ms » dans une section et « interroger l’API externe pour des données en temps réel » dans une autre, le modèle ne signalera pas la tension. Il tentera les deux, et le résultat sera subtilement brisé selon l’instruction qu’il aura priorisée.
Le flot logique est là où vit le vrai risque. Le code fonctionne. La syntaxe est propre. Les noms de variables sont sensés. Mais la logique fait quelque chose de légèrement différent de ce que nous voulions, et l’écart est assez petit pour échapper à une révision rapide. C’est là que le jugement (compétence 2) et l’évaluation se croisent : il faut savoir à quoi ressemble « juste » avant de pouvoir repérer ce qui est subtilement faux.
Bâtir l’instinct
La bonne nouvelle, c’est que l’évaluation, comme chaque compétence de cette série, s’apprend. Et ses effets se cumulent. Chaque erreur que nous attrapons nous enseigne où regarder la prochaine fois.
Commencez par les limites. Qu’arrive-t-il à zéro? Au maximum? Quand l’entrée est manquante ou malformée? Ce ne sont pas des scénarios exotiques. Ce sont les scénarios que les vrais utilisateurs rencontrent dès le deuxième jour, et ce sont précisément les scénarios que l’IA gère avec des absurdités à l’air plausible.
Vérifiez les coutures. Quand nous décomposons un problème (compétence 3) et orchestrons plusieurs agents (compétence 4), les erreurs se concentrent là où les pièces se rejoignent. Chaque pièce fonctionne à merveille en isolation. Ensemble, elles font l’une sur l’autre des suppositions que personne n’a vérifiées.
Lisez le résultat en sceptique, pas en admirateur. Nos cerveaux sont câblés pour faire confiance à ce qui sonne articulé. C’est le piège. La fluidité n’est pas l’exactitude. L’assurance n’est pas la justesse. La posture mentale la plus utile pour l’évaluation n’est pas « voyons si c’est faux » mais « trouvons où c’est faux ». Le passage du si au où change la manière dont nous lisons.
Révisez le résultat, pas le plan
Une des leçons les plus contre-intuitives des équipes plongées dans les flux de travail IA : cessez de réviser le plan. Révisez le résultat.
Révisez tôt les artéfacts courts : une discussion de conception de deux pages, un plan de structure. C’est là que les mauvaises décisions s’attrapent à peu de frais. Ensuite, laissez l’agent implémenter, et révisez ce qu’il a réellement produit. Le plan n’a jamais été qu’une hypothèse. Le résultat, c’est la vérité.
Une cible qui mérite d’être énoncée sans détour : visez deux à trois fois la productivité, pas dix. Le levier durable vient de la qualité, pas de la vélocité. Aller dix fois plus vite ne sert à rien si nous jetons tout dans six mois.
Le paradoxe de la confiance
Les gens qui font le moins confiance à l’IA ne sont pas les meilleurs évaluateurs. Ceux qui lui font le plus confiance non plus. Les meilleurs évaluateurs sont ceux qui lui font exactement assez confiance : assez pour la laisser travailler, pas assez pour la laisser livrer sans contrôle.
C’est une compétence que les bons gestionnaires ont toujours dû avoir. Faire assez confiance à la nouvelle recrue pour la laisser travailler de façon autonome; vérifier les livrables avant qu’ils atteignent le client. La confiance sans vérification est de la naïveté. La vérification sans confiance est de la paralysie. La compétence, c’est de calibrer entre les deux.
L’IA ne change pas cette dynamique. Elle l’accélère. Le volume est plus grand. La surface des erreurs subtiles est plus large. Mais la compétence fondamentale est la même que celle que les professionnels d’expérience développent depuis des décennies : savoir où regarder, savoir à quoi ressemble le faux, et savoir quand quelque chose qui semble correct mérite un second regard.
À Montréal, où la recherche en interprétabilité de Mila a montré que les modèles développent des états internes qui s’apparentent à des émotions, la question de l’évaluation prend une dimension supplémentaire. Un modèle qui « se sent » calme peut en réalité être moins soigneux qu’un modèle qui « se sent » frustré. L’intuition voulant qu’un système détendu soit un système sûr se révèle fausse. L’évaluation, autrement dit, exige de comprendre non seulement le résultat, mais l’état qui l’a produit.
La boucle se referme
C’est la sixième et dernière compétence de cette série, et ce n’est pas un hasard qu’elle arrive en dernier.
Nous avons commencé par la spécification, puis le jugement, la décomposition, l’orchestration et l’intention. L’évaluation referme la boucle. Si le résultat est faux, l’évaluation nous dit quelle compétence a flanché. La spec était-elle ambiguë? Avons-nous mal décomposé? L’intention était-elle floue? Ce n’est pas seulement la vérification finale. C’est le mécanisme de rétroaction qui améliore chacune des autres compétences avec le temps.
Ces six compétences ne sont pas un programme d’études. Ce sont une pratique. Nous nous y améliorons graduellement, par l’usage, par les erreurs, par la lente accumulation de ce savoir : où les choses dérapent, et comment les attraper plus tôt la prochaine fois.
Où nous en sommes
L’économie se scinde. C’est réel, et prétendre le contraire n’aide personne. Mais l’écart entre les deux trajectoires n’est pas le talent, les diplômes, ni les années d’expérience dans une technologie précise. C’est un ensemble de compétences, six, qui s’apprennent, se pratiquent et se cumulent. Chaque semaine passée à développer ces compétences creuse l’avantage, parce que les outils gagnent en puissance, et que les gens capables de les diriger et de les vérifier prennent de la valeur, ils n’en perdent pas.
Ce n’est pas un avertissement. C’est une invitation. Les outils sont extraordinaires. Les occasions qu’ils créent sont réelles. Et les compétences requises pour saisir ces occasions ne sont ni mystérieuses ni réservées. Ce sont la spécification, le jugement, la décomposition, l’orchestration, l’intention et l’évaluation. Nous avons consacré six articles à les examiner une à une.
Le guide du voyageur est complet. Le voyage, lui, ne l’est pas. Mais nous connaissons maintenant les compétences. Le reste, c’est de la pratique.
Ceci est le sixième et dernier article du « Guide du voyageur de l’économie en K », une série sur les compétences humaines qui comptent le plus à l’ère de l’IA. La série complète : Spécification, Jugement, Décomposition, Orchestration, Intention, et Évaluation.