Un pilote d’IA peut fonctionner sur le plan technique et ne rien changer du tout. Il produit des réponses prometteuses, et ces réponses n’entrent jamais dans une décision qui compte.
Avec les agents, l’enjeu monte d’un cran. Le pilote ne fait plus seulement répondre. Il agit. Alors avant de l’élargir, je veux savoir qui porte la décision qu’il touche, ce qui devrait changer pour que le système puisse l’appuyer, et ce qu’il peut faire sans qu’une personne le révise.
Qui porte le résultat opérationnel?
Un comité peut parrainer un projet. Il faut quand même quelqu’un d’imputable pour la décision ou le processus que le projet doit améliorer.
Cette personne devrait aider à définir le succès et trancher les compromis qui apparaissent pendant la mise en œuvre. Le chargé de projet qui suit les jalons n’est souvent pas la personne qui devra vivre avec le résultat dans les opérations.
Demandez qui va entretenir la capacité, suivre sa performance et décider quoi faire quand elle échoue, une fois l’équipe de projet passée à autre chose.
Quel contexte manque-t-il?
Un modèle ne sait pas à quelle source votre équipe se fie, ce que veut dire un terme fournisseur, ou pourquoi un cas qui a l’air simple demande une exception.
Une partie de ce savoir est dans les systèmes. Une autre est dans la tête des gens qui font le travail. Le rendre explicite peut vouloir dire changer les données, la documentation ou le processus lui-même.
Pour un agent qui utilise des outils, le contexte, ce sont aussi des limites : ce qu’il peut lire, ce qu’il peut modifier et quand il doit demander. Une réponse plausible, ce n’est pas une permission d’agir.
Comment les gens vont-ils utiliser le résultat?
Un résultat utile peut quand même arriver au mauvais moment ou en dehors des outils que les gens utilisent. Il peut aussi créer du travail de vérification que personne n’avait prévu.
Faites le tour complet de la tâche avec les gens qui vont utiliser le système. Regardez ce qui se passe avant qu’on l’appelle, comment quelqu’un vérifie son travail et ce qui vient après. Incluez les cas flous et les échecs, pas seulement la démo qui marche bien.
Un premier geste concret
Choisissez un processus qui compte, mais aux contours clairs. Nommez son responsable et ses utilisateurs, documentez le contexte dont il a besoin et décidez comment vous allez comparer le résultat à la façon de faire actuelle.
Bâtissez ensuite le plus petit test utile. Gardez assez de visibilité pour voir ce que le système a fait, et précisez qui peut approuver, corriger ou arrêter ses actions. N’élargissez pas ses permissions tant que ces preuves ne sont pas là.
Le résultat devrait vous dire si la capacité mérite un plus grand rôle, et ce que l’organisation doit changer avant de le lui donner.