Études & Réflexions › Outils de pilotage : comment vérifier qu'ils sont encore fiables ?

L'actualité remet la transparence des outils sur la table

Le 24 juillet 2026, l'Union européenne a publié le règlement (UE) 2026/1744, qui a reporté au 2 décembre 2027 l'application d'une partie importante des exigences prévues pour les systèmes d'IA à haut risque relevant de l'annexe III du règlement sur l'intelligence artificielle : des exigences qui portent notamment sur la documentation, la transparence et la supervision humaine de ces systèmes (recrutement, notation de crédit, éducation, biométrie, entre autres).

Ce report ne dispense donc de rien : il déplace une échéance pour une catégorie de systèmes précisément définie. Mais il remet une question sur la table qui dépasse largement cette catégorie : quand un outil produit un résultat qui sert à décider, qui, dans l'organisation, peut encore expliquer comment ce résultat est obtenu ?

Le problème existait bien avant l'intelligence artificielle

Cette question ne commence pas avec l'intelligence artificielle. Une règle de gestion peut naître dans un tableur : une formule qui calcule un risque, une marge ou une priorité. Avec le temps, cette même règle peut être reprise dans une requête pour traiter davantage de données, puis automatisée dans un script pour éviter de la ressaisir, puis intégrée dans une application métier pour la rendre accessible à toute une équipe. Elle peut demain être complétée par un modèle statistique ou un système d'intelligence artificielle.

À chaque étape, l'outil devient en général plus puissant, plus rapide, ou plus simple à utiliser pour celui qui consulte son résultat. Mais l'organisation peut perdre, progressivement et sans s'en apercevoir, autre chose : la capacité à expliquer comment ce résultat est produit. Son concepteur quitte l'entreprise. Une règle est ajoutée une année, sans que la précédente soit retirée. Une formule devient du code. Une requête est modifiée pour traiter un cas particulier, sans que la modification soit documentée. Une source de données change de format ou de fournisseur. Une règle métier, pertinente au moment où elle a été écrite, ne correspond plus tout à fait au contexte dans lequel elle continue de s'appliquer. L'application, en devenant plus ergonomique, finit par masquer les calculs intermédiaires qu'un tableur montrait par défaut.

Le résultat n'est pas un outil devenu mystérieux ou dangereux. C'est une situation beaucoup plus banale : la confiance dans un résultat ne devrait pas dépasser la compréhension qu'on a de la règle qui le produit. Dans beaucoup d'organisations, c'est pourtant l'inverse qui s'installe avec le temps. Les utilisateurs connaissent le chiffre, mais ne savent plus toujours d'où il vient.

Des données fiables ne suffisent pas

Face à ce constat, le réflexe le plus courant consiste à vérifier la qualité des données : sont-elles complètes, à jour, correctement saisies ? C'est nécessaire, mais ça ne suffit pas.

Une entreprise peut disposer de données parfaitement fiables et produire malgré tout un résultat discutable, si la règle qui les transforme est mauvaise, devenue obsolète, mal paramétrée, ou appliquée hors du périmètre pour lequel elle avait été conçue. À l'inverse, une règle de calcul bien conçue, appliquée à des données erronées ou incomplètes, produira elle aussi un résultat sur lequel il serait imprudent de s'appuyer.

La fiabilité d'un outil de pilotage se regarde donc à plusieurs niveaux : les données qui l'alimentent, la règle qui les transforme, le comportement observé de l'outil, et l'usage qui en est fait dans une décision. Des données fiables ne suffisent pas si plus personne, dans l'organisation, ne maîtrise la règle qui les transforme en indicateur, en note ou en recommandation.

Quatre questions pour vérifier un outil de pilotage

Cette méthode ne dépend pas de la technologie utilisée. Elle s'applique à un tableur comme à une requête, un script, une application métier, un moteur de règles ou un modèle statistique.

Que décide-t-on à partir de son résultat ?

Un résultat peut servir de simple indicateur d'information, déclencher une alerte, alimenter une recommandation, produire un classement ou une note, ou conduire à une décision quasiment automatique. Plus il pèse sur une décision importante, plus le niveau de maîtrise attendu doit être élevé : ce n'est pas une question de tout ou rien, mais de proportion entre l'exigence de compréhension et l'enjeu de la décision.

Peut-on retracer les données et la règle qui le produisent ?

Pour le résultat identifié à l'étape précédente, l'organisation doit pouvoir répondre simplement : quelles données entrent dans le calcul, d'où viennent-elles, quelles règles les transforment, quels seuils ou paramètres influencent le résultat, et qui peut aujourd'hui expliquer ou faire évoluer ces règles ? Il ne s'agit pas de savoir lire le code qui exécute le calcul. Comprendre un outil ne signifie pas savoir lire son code ou sa formule ; cela signifie pouvoir expliquer les données et les règles métier qui produisent le résultat utilisé pour décider.

Son comportement correspond-il à ce qu'on attend de lui ?

Il s'agit de tester l'outil, pas seulement de vérifier qu'il retombe sur des cas déjà connus. Cela peut passer par des dossiers dont l'issue réelle est connue, mais aussi par des cas limites, des cas volontairement construits, ou par la modification d'une donnée importante pour observer si le résultat évolue dans le sens attendu par la règle métier. L'objectif est de repérer les situations où le résultat devient moins fiable : une donnée manquante, un cas hors du périmètre pour lequel la règle a été conçue, un changement de contexte que la règle n'a pas suivi. La question n'est pas de savoir si l'outil obtient toujours la bonne réponse, un petit nombre de tests ne le démontre jamais, mais s'il se comporte comme l'organisation pense qu'il se comporte, et dans quelles situations il faut s'en méfier.

À partir de quand faut-il une revue humaine ?

La proximité d'un seuil est une raison de revue humaine, mais ce n'est pas la seule. Un montant financier important, une donnée manquante ou inhabituelle, un cas en dehors du périmètre habituel de l'outil, une incohérence détectée entre plusieurs indicateurs, une décision difficilement réversible, ou une limite déjà connue de l'outil justifient tout autant qu'une personne examine le résultat avant qu'il ne devienne une décision.

Ces quatre questions ne dépendent d'aucune technologie particulière. Elles ne demandent ni de réécrire l'outil, ni d'attendre une obligation réglementaire pour se les poser.

Un exemple pour rendre ça concret

Prenons un cas fictif, mais réaliste. Une PME industrielle évaluait depuis des années, à l'aide d'un tableur, le risque de retard de paiement de ses clients avant de leur accorder un délai. Le tableur, devenu trop lourd à maintenir, a été transformé en un outil interne qui calcule automatiquement une note à partir de l'historique de paiement, du secteur d'activité et de l'encours en cours. La personne qui avait construit cette logique a depuis quitté l'entreprise.

Aujourd'hui, l'équipe commerciale utilise cette note pour accorder ou refuser un délai de paiement, sans que personne ne puisse en détailler précisément le calcul. En appliquant la méthode, la décision influencée est d'abord posée clairement : accorder ou non un délai, et selon quelles conditions. Les données et les règles sont ensuite reconstituées auprès du prestataire qui maintient l'outil, à défaut de la personne qui l'a conçu : quelles données clients entrent dans le calcul, comment sont-elles pondérées, quels seuils déclenchent un refus, qui peut aujourd'hui modifier ces seuils. L'outil est alors testé sur des dossiers dont l'issue réelle est connue, mais aussi sur des cas limites construits pour l'occasion : que se passe-t-il si l'encours augmente brutalement, si un client change de secteur d'activité, si une donnée d'historique manque ? Le comportement observé est comparé à ce que la règle métier est censée produire. Des conditions de revue humaine sont enfin définies : un encours particulièrement important, une note proche de la limite de refus, une donnée manquante ou inhabituelle, ou une situation hors du périmètre habituel font repasser la décision par une validation du directeur financier avant d'être appliquée.

Le résultat n'est pas de refaire l'outil. C'est de savoir ce qu'il fait, dans quelles conditions s'y fier, et à partir de quand il faut le vérifier.

Ce que cela change pour le pilotage

Le fait institutionnel est clair : le règlement européen sur l'intelligence artificielle a reporté au 2 décembre 2027 une partie importante de ses exigences applicables aux systèmes à haut risque relevant de l'annexe III. Mais ce calendrier ne concerne qu'une catégorie précise de systèmes, et il ne dit rien de la question plus large que rencontre toute organisation qui pilote avec des outils, tableur, requête, script, application ou modèle, avec ou sans intelligence artificielle.

Cette question ne dépend d'aucune obligation légale pour se poser. Elle se pose dès qu'une organisation délègue une décision, petite ou grande, à un outil dont elle ne sait plus expliquer la logique. Le report réglementaire de 2026 à 2027 ne change rien à cela : il déplace une échéance de conformité, pas le moment où il devient utile de comprendre ce qu'un outil fait réellement.

FAQ

Comment savoir si un outil de pilotage est encore fiable ?

En vérifiant quatre éléments : quelles décisions il influence réellement, si les données et les règles qui produisent son résultat peuvent encore être expliquées, si son comportement correspond à ce qu'on attend de lui sur des cas connus et des cas limites, et à partir de quel seuil son résultat doit être revu par une personne avant de devenir une décision.

Faut-il comprendre le code d'un outil pour pouvoir lui faire confiance ?

Non. Comprendre un outil ne signifie pas savoir lire son code ou sa formule. Cela signifie pouvoir expliquer les données qui l'alimentent et les règles métier qui produisent le résultat utilisé pour décider, ce qui reste possible sans compétence en programmation.

À quelle fréquence faut-il revoir les règles d'un outil de pilotage ?

Il n'existe pas de fréquence standard. Une revue devient particulièrement pertinente lorsqu'un élément important change : une source de données, une règle métier, un paramètre, un processus, une réglementation, le responsable de l'outil, ou l'usage fait du résultat dans la décision. La fréquence dépend du risque associé à la décision et des changements qui affectent l'outil, pas d'un calendrier universel.

Brice Béchet

Consultant en pilotage des organisations

Contrôleur de gestion sénior, data scientist et créateur d'effectivo.fr, application de prévision stratégique des effectifs (Anticipez. Simulez. Décidez), j'accompagne les organisations à structurer leurs données et optimiser leur pilotage.

En savoir plus LinkedIn