Votre IA répond. Savez-vous quand elle se trompe ?

Le silence n'est pas une preuve

Les faux positifs se voient. Une alerte inutile agace un collaborateur, qui la corrige ou la ferme. Les faux négatifs ne font pas de bruit.

Un contrôle oublié. Une période mal sélectionnée. Une pièce indisponible interprétée comme une absence d'opération. Une exception ancienne réappliquée alors que la situation a changé.

Le dossier paraît calme. La réponse paraît cohérente. Rien ne vous oblige à ouvrir ce qui n'a pas été signalé. Voilà pourquoi vérifier seulement les alertes ne suffit pas. Il faut aussi examiner les silences.

Comparer les modèles ne répond pas à cette question

Quel modèle raisonne le mieux ? Lequel accepte le plus de documents ? Lequel coûte le moins cher ? Ces questions sont utiles. Elles ne remplacent pas celle-ci : est-ce que le système fonctionne sur nos dossiers, avec nos données, nos règles et nos contraintes ?

Un benchmark public renseigne sur une épreuve donnée. Il ne vérifie pas votre connecteur, votre calcul de provision ni la manière dont une décision de votre chef de mission sera réutilisée six mois plus tard.

Et un bon score moyen peut masquer l'erreur qui compte vraiment. En finance, toutes les erreurs n'ont ni le même poids ni les mêmes conséquences.

La discipline s'appelle l'évaluation

Le principe : réunir des cas dont le résultat attendu est établi, puis vérifier ce que le système produit. Les équipes techniques parlent d'evals et de tests de non-régression. Un jeu de référence, souvent appelé golden set, permet de rejouer ces épreuves après un changement.

C'est proche de la logique des tests unitaires. Mais il faut aussi tester le parcours entier : de la lecture des données à la conclusion présentée au professionnel.

La bonne réponse n'est d'ailleurs pas toujours une alerte. Parfois, c'est une demande de pièce. Parfois, c'est : « Je ne peux pas conclure sur cette période. » Un système capable de reconnaître cette limite est plus utile qu'un système qui remplit toujours la case.

Première exigence : regarder les erreurs

On reprend un cas. On examine les pièces disponibles à la date du contrôle. On lit les traces : ce qui a été demandé, ce qui a été obtenu, ce qui a échoué, la règle appliquée.

Puis on écrit ce qui cloche. Simplement. « Le montant est juste, mais pas la période. » « L'explication cite une pièce qui ne la démontre pas. » « L'absence d'alerte vient d'une lecture incomplète. »

Cette analyse donne un test beaucoup plus précis qu'une nouvelle instruction demandant au modèle d'être rigoureux.

Deuxième exigence : réunir expertise comptable et ingénierie

Le professionnel sait ce qui mérite une alerte, quelle information manque et dans quelles limites un arbitrage reste valable. L'ingénieur transforme cet attendu en contrôle reproductible. Il vérifie les montants, les dates, les périmètres et la couverture réelle. L'un ne remplace pas l'autre.

Faire valider un cas par un expert permet ensuite de le tester automatiquement. Cela ne signifie pas que l'expert signe chaque réponse future de l'IA. Et cela ne transfère pas au cabinet la responsabilité des défauts du produit.

Quant au juge LLM, notre règle est simple : le réserver à ce qu'un test déterministe ne sait réellement pas vérifier. Pas ajouter un deuxième modèle pour rassurer sur le premier.

Troisième exigence : ne pas attendre un an

La revue annuelle est utile pour revalider les cas, les règles et leurs limites. Mais si le connecteur change mardi, attendre la prochaine clôture pour découvrir une régression n'est pas une stratégie de contrôle.

Il faut les deux : une référence métier entretenue par les professionnels et des évaluations rejouées à chaque modification pertinente. Le temps nécessaire se mesure pendant le pilote. Il ne se promet pas à coups de « trente minutes par semaine » avant d'avoir essayé.

Mesurer, c'est accepter de découvrir un mauvais résultat

Une démonstration montre ce que l'IA peut réussir. Une évaluation cherche aussi les circonstances dans lesquelles elle échoue. La seconde est moins confortable. C'est précisément son intérêt.

Chez HOLCO, c'est le principe du protocole que nous avons formalisé : partir des révisions, établir les attendus avec les professionnels, puis rendre leur vérification reproductible. Une méthode écrite n'est pas encore une performance prouvée. Les résultats devront être mesurés et présentés avec leurs limites.

Commencez par quelques cas documentés. Des alertes, des silences, des exceptions et des lectures impossibles. Un tableur peut suffire pour organiser les premiers attendus. Il ne remplace ni les preuves ni les tests.

La question n'est pas seulement : « Quelle IA utilisez-vous ? » C'est : « Comment savez-vous quand elle se trompe ? »