Approche
Partir de la décision publique, pas de l’outil.
Une technologie n’a de valeur que si l’organisation sait expliquer ce qu’elle change, vérifier ce qu’elle produit et reprendre la main lorsqu’elle échoue.
Ligne de travail
Rendre la capacité vérifiable
Une démonstration convaincante ne constitue pas encore un service. Avant de généraliser, il faut définir la décision attendue, l’état initial, les responsabilités, les critères d’essai, les conditions de sortie et la solution non-IA avec laquelle comparer.
Cette discipline vaut pour un assistant documentaire, une automatisation, un système métier, un réseau d’objets connectés ou une infrastructure mutualisée.
Six questions
Ce qu’un projet doit pouvoir expliquer
- 01
Quel problème public précis traitons-nous ?
Le besoin doit être observable et suffisamment important pour justifier une intervention.
- 02
Quelle décision l’essai doit-il éclairer ?
Un pilote sans décision prévue accumule des impressions, pas des preuves.
- 03
Quelles données et dépendances engageons-nous ?
Sources, droits, qualité, flux, journaux, sous-traitants et infrastructures doivent être visibles.
- 04
Qui reste responsable ?
L’automatisation ne doit ni diluer le jugement ni rendre l’erreur sans propriétaire.
- 05
Comment savons-nous que cela fonctionne ?
Critères, seuils et scénarios d’échec sont définis avant l’essai.
- 06
Comment sortons-nous ?
Réversibilité, récupération, compétences et coûts de remplacement font partie du service.
Avocat du diable
La meilleure décision peut être de ne pas utiliser l’IA.
Une règle plus claire, une donnée mieux tenue, une simplification du processus ou un outil déterministe peuvent apporter davantage de valeur, avec moins de risques et de dépendances.