Réponse courte. Diriger avec la data et l'intelligence artificielle ne consiste pas à ajouter un tableau de bord ou un chatbot à chaque équipe. Pour moi, il faut organiser une boucle simple. Une donnée utile change une décision nommée. Une IA utile produit une proposition que l'on peut inspecter. Une personne valide cette proposition et reste responsable du choix. Enfin, un journal relie le signal observé, l'hypothèse, l'action, le résultat et la règle à retenir. Sans cette boucle, l'entreprise produit plus d'analyses. Elle ne décide pas forcément mieux.
Retour d'opérateur, 28 octobre 2026.
La recherche sur ce sujet mène souvent vers des formations pour cadres dirigeants. La page de HEC Paris présente une formation consacrée à la stratégie Data/IA. Ici, je prends un autre angle : celui d'un opérateur international qui doit faire passer une information jusqu'à une décision, puis vérifier ce que cette décision a produit.
Pourquoi les tableaux de bord ne suffisent-ils pas ?
Un tableau de bord décrit une situation. Il peut montrer une baisse, une hausse ou un écart. Il ne dit pas toujours qui doit décider, dans quel délai, ni ce qui doit changer.
C'est là que beaucoup de démarches se bloquent. L'équipe mesure davantage, mais la réunion reste la même. Chacun commente les chiffres. Personne ne nomme la décision ouverte. La donnée devient un sujet de conversation au lieu de devenir un outil de direction.
Je pars donc d'une question simple : quelle décision ce signal peut-il modifier ?
Si personne ne peut répondre, le signal n'est peut-être pas inutile. Mais il n'est pas encore prêt à entrer dans la boucle de décision. Il faut préciser son usage, son seuil et son propriétaire.
Une donnée exploitable doit au moins permettre de répondre à ces questions :
- Quel changement observons-nous ?
- Quelle décision pourrait changer à cause de ce signal ?
- Qui prend cette décision ?
- Quelle action suit si le seuil est franchi ?
- Quel résultat permettra de juger l'action ?
Cette discipline évite de confondre richesse d'information et capacité d'action.
Quelle place donner à l'intelligence artificielle ?
Je ne demande pas d'abord à l'IA de décider. Je lui demande de produire une proposition inspectable.
Cette proposition peut prendre plusieurs formes :
- un résumé des signaux qui ont changé ;
- une hypothèse sur la cause d'un écart ;
- plusieurs actions possibles, avec les éléments qui les soutiennent ;
- un brouillon de décision à valider ;
- une liste des données manquantes ou contradictoires.
Le mot important est inspectable. Une sortie utile permet à une personne de voir les éléments utilisés, de repérer une erreur et de refuser la recommandation. Une réponse fluide mais impossible à contrôler ajoute du risque au moment même où elle prétend réduire l'incertitude.
Cette approche rejoint ma façon plus large de penser l'utilisation de l'intelligence artificielle : la valeur ne vient pas du volume de texte généré. Elle vient du lien entre une sortie et un travail réel.
Pour approfondir le sujet, le dossier public officiel de la CNIL consacré à l'intelligence artificielle constitue un point d'entrée utile.
Qui reste responsable de la décision ?
La validation humaine n'est pas une formalité placée à la fin du processus. Elle garde la responsabilité à un endroit clair.
Cela suppose de nommer une personne. Un comité diffus ne suffit pas. Le propriétaire de la décision peut écouter plusieurs avis, demander une nouvelle analyse ou rejeter la proposition de l'IA. Mais il doit pouvoir expliquer le choix final.
Pour garder cette responsabilité concrète, je vérifie quatre points :
- la personne connaît la décision qu'elle valide ;
- elle peut consulter les signaux et les hypothèses ;
- elle peut modifier ou refuser l'action proposée ;
- son choix et sa raison entrent dans le journal de décision.
L'IA peut accélérer la lecture et préparer des options. Elle ne doit pas rendre l'auteur de la décision introuvable.
Comment construire une boucle de décision vérifiable ?
Ma boucle publique DBO suit cet ordre exact : Diag → Test → Build → Operate → Improve.
Elle permet de ne pas sauter directement d'un signal à un grand chantier.
Diag. On décrit l'écart et la décision concernée. On sépare ce que l'on sait de ce que l'on suppose.
Test. On cherche le moyen le plus simple de vérifier l'hypothèse. Le test doit produire une information utile pour la suite.
Build. On construit ce qui a été confirmé. Cela peut être un flux de données, une règle, une interface ou une étape de contrôle.
Operate. On fait fonctionner le dispositif dans le travail courant. C'est ici que l'on voit si les rôles, les délais et les données tiennent hors d'une démonstration.
Improve. On compare le résultat à l'hypothèse. Puis on garde, corrige ou retire la règle.
Cette boucle ne vaut que si chaque étape laisse une trace. Le but n'est pas de documenter pour documenter. Il est de pouvoir revenir sur une décision sans reconstruire son histoire de mémoire.
À quoi ressemble le registre minimum ?
Le registre tient sur cinq colonnes. Chaque ligne correspond à une décision réelle, pas à un indicateur isolé.
| Signal | Décision | Action | Preuve | Propriétaire |
|---|---|---|---|---|
| Ce qui a changé, avec sa date et sa source | Le choix précis qui peut être modifié | Ce qui sera fait et quand | Le résultat attendu et la mesure retenue | La personne qui valide et répond du choix |
Dans le journal complet, j'ajoute l'hypothèse avant l'action et la prochaine règle après le résultat. On obtient alors une chaîne lisible :
signal → hypothèse → action → résultat → prochaine règle
Cette chaîne apporte deux choses. D'abord, elle rend le raisonnement contrôlable avant l'action. Ensuite, elle crée une mémoire après l'action. Une équipe peut voir pourquoi une règle existe, quand elle a été créée et ce qui pourrait justifier sa révision.
Comment cette méthode fonctionne-t-elle dans un cas fictif ?
Exemple fictif : une équipe éditoriale internationale. Cet exemple sert seulement à montrer la mécanique. Il ne décrit ni un client ni un résultat réel.
L'équipe observe que plusieurs articles récents reçoivent des visites, mais que peu de lecteurs poursuivent vers une page liée. Le signal est daté et relié aux pages concernées.
La décision ouverte n'est pas « faut-il améliorer le contenu ? ». Cette formule est trop vague. La vraie décision est : faut-il modifier la manière dont les articles orientent vers l'étape suivante ?
L'IA analyse les pages et produit une proposition inspectable. Elle indique les passages où un lien pourrait répondre à la question suivante du lecteur. Elle cite les extraits concernés et distingue ses hypothèses des faits observés.
La personne responsable relit la proposition. Elle rejette certains ajouts, car ils détourneraient le lecteur. Elle valide un petit test sur un groupe limité de pages et note sa raison dans le journal.
Le test compare ensuite le comportement observé avec le point de départ. L'équipe ne demande pas seulement si un chiffre a bougé. Elle vérifie aussi si les liens restent utiles et cohérents avec le texte.
À la fin, trois issues sont possibles :
- Le résultat soutient l'hypothèse. L'équipe transforme le choix en règle claire.
- Le résultat reste ambigu. Elle ajuste le test ou collecte un signal plus précis.
- Le résultat contredit l'hypothèse. Elle abandonne l'idée et conserve la trace de cet échec.
Le dernier cas compte autant que le premier. Un journal de décision empêche une idée invalidée de revenir six mois plus tard sous un autre nom.
Pour voir une autre façon de rendre la démarche concrète, on peut lire cet exemple de projet d'intelligence artificielle.
Quelles erreurs empêchent de mieux diriger ?
La première erreur consiste à partir de l'outil. La question devient « où placer l'IA ? » alors qu'elle devrait être « quelle décision doit devenir plus rapide, plus claire ou mieux vérifiée ? »
La deuxième consiste à suivre trop de signaux. Quand chaque variation déclenche une alerte, l'attention se disperse. Un signal doit être lié à un seuil, à une décision et à un propriétaire.
La troisième consiste à accepter une réponse impossible à examiner. Une recommandation sans données citées, sans hypothèses visibles ou sans possibilité de refus ne peut pas entrer proprement dans la boucle.
La quatrième consiste à tester sans écrire le résultat attendu. Après coup, chacun peut raconter que le test confirme son intuition. Une preuve doit être définie avant l'action.
La cinquième consiste à accumuler les décisions sans revoir les règles. Une boucle n'est complète que lorsque le résultat modifie la façon de décider la prochaine fois.
Par où commencer sans lancer un grand programme ?
Je commencerais par une seule décision fréquente. Elle doit avoir un propriétaire clair et produire un résultat observable dans un délai raisonnable.
Le premier cycle peut rester très simple :
- Nommer la décision et son propriétaire.
- Choisir un signal qui peut réellement changer cette décision.
- Définir ce que l'IA prépare et ce qu'elle ne décide pas.
- Écrire le critère de preuve avant d'agir.
- Consigner le choix, le résultat et la prochaine règle.
Ce point de départ a un avantage pratique. Il teste la qualité des données, la place de l'IA et la responsabilité humaine dans un même mouvement. Il révèle aussi les frictions réelles. Une donnée arrive trop tard. Une sortie ne cite pas ses sources. Deux personnes pensent posséder la même décision. Ces problèmes sont plus utiles qu'une longue liste d'usages théoriques, car ils montrent ce qu'il faut corriger.
Sur la page d'accueil, je présente la galaxie dont Tileo et loic-guyon forment l'ancre personnelle. Si vous cherchez le bon point d'entrée selon votre besoin, vous pouvez Choisir la bonne porte.
FAQ
Faut-il centraliser toutes les données avant de commencer ?
Non. Cette méthode peut commencer avec les données nécessaires à une décision précise. Le test montrera ensuite les manques qui bloquent vraiment l'action.
L'IA peut-elle prendre seule une décision de direction ?
Dans ma méthode, non. Elle prépare une proposition inspectable. Une personne nommée la valide, la modifie ou la refuse et reste responsable du choix.
Quelle différence entre un tableau de bord et un journal de décision ?
Le tableau de bord montre des signaux. Le journal relie un signal à une hypothèse, une action, un résultat et une règle suivante. Il conserve le raisonnement, pas seulement la mesure.
Comment savoir si une donnée est utile ?
Demandez quelle décision elle peut changer. Si aucune décision n'est nommée, précisez son usage avant de l'ajouter au dispositif de direction.
Quel est le rôle exact de la preuve ?
La preuve permet de juger l'action selon un critère défini à l'avance. Elle évite de réécrire l'objectif une fois le résultat connu.
La boucle DBO est-elle une norme générale ?
Non. Diag → Test → Build → Operate → Improve est ma boucle publique et ma méthode personnelle. Elle décrit la façon dont j'organise le passage d'un signal à une règle améliorée.