Consultant IA : cadrer un premier cas d’usage avant de choisir un outil

1. Le problème métier vient avant l’outil

Une démonstration peut impressionner sans prouver qu’elle améliore une décision réelle.

Un outil n’est pas un cas d’usage. « Utiliser une IA générative pour le support » ne précise ni le travail à faire, ni la personne responsable, ni l’erreur qui pourrait nuire au client. Un cadrage plus solide décrit une situation : à partir d’une demande et d’une base documentaire autorisée, le système prépare un brouillon ; une personne identifiée vérifie les faits, choisit la réponse et décide de l’envoyer ou non.

Cette distinction change la mission du consultant IA. Son rôle n’est pas seulement de connaître des solutions. Il doit aider l’organisation à formuler le problème, repérer les dépendances, rendre les critères observables et organiser un essai réversible. Les capacités techniques restent importantes, mais elles servent une décision déjà définie.

L’accompagnement de consultant en IA appliquée présenté par Ayoub Kahouadji relie précisément usages, workflows et automatisation. Ses méthodes publiques ajoutent la logique de contrôle, tandis que son dossier sur l’IA en entreprise replace le choix des outils après celui des usages.

2. Nommer la décision concernée

La sortie produite par l’IA et la décision prise par une personne sont deux objets différents.

Un résumé, un classement, une suggestion ou un brouillon est une sortie. Accepter une dépense, publier un contenu, répondre à un prospect ou modifier une procédure est une décision. Confondre les deux conduit à déléguer trop tôt une responsabilité au système.

Le cadrage doit préciser qui utilise la sortie, ce que cette personne peut décider, ce qu’elle ne peut pas déléguer et quelles preuves elle doit consulter. Pour un usage éditorial, par exemple, la génération d’un plan ne vaut pas validation d’un article. Le responsable reste chargé de vérifier les sources, le sens, la conformité au ton et la pertinence de la publication.

Il faut aussi décrire la situation actuelle sans la caricaturer. Quel document déclenche le travail ? Où l’information est-elle cherchée ? Quelles vérifications sont déjà faites ? Quel est le chemin d’escalade ? Cette cartographie révèle parfois qu’une règle, un modèle de document ou un meilleur accès à l’information résout une partie du problème sans IA.

3. Délimiter les entrées et les données autorisées

La qualité d’un test dépend autant de la provenance et des droits sur les données que du modèle choisi.

Avant un essai, l’équipe liste chaque entrée : document interne, donnée publique, instruction, historique, champ de formulaire ou référence métier. Pour chacune, elle note l’origine, la personne qui peut y accéder, la durée utile, les informations sensibles possibles et les conditions d’utilisation par le fournisseur envisagé.

Cette étape ne doit pas se limiter à « données personnelles : oui ou non ». Une information peut être confidentielle sans identifier une personne ; un document public peut être obsolète ; une base autorisée pour la consultation peut ne pas l’être pour l’entraînement ou la réutilisation. Le cadrage sépare donc les données admises, interdites et soumises à une validation préalable.

La CNIL recommande de partir de besoins concrets, d’examiner les risques et les limites, de définir des règles d’usage et de ne pas reprendre aveuglément les réponses d’un système d’IA générative. Pour le pilote, cette prudence devient une règle opérationnelle : on privilégie des données synthétiques ou préparées tant que les accès, les contrats et les finalités ne sont pas clarifiés.

Une consigne d’utilisation appartient elle aussi aux entrées. Elle doit être versionnée avec le jeu de tests. Sans cette trace, une amélioration apparente peut provenir d’un changement de formulation plutôt que du produit évalué, ce qui rend la comparaison peu fiable.

• Nommer le propriétaire de chaque source d’information.
• Séparer les données de test des données d’exploitation.
• Documenter les champs interdits avant de préparer les exemples.
• Conserver la version des instructions utilisée pendant l’évaluation.
• Prévoir une suppression ou une révocation d’accès lorsque le test s’arrête.

4. Construire le jeu de tests avant la démonstration

Un test préparé à l’avance réduit le risque de choisir uniquement les exemples qui mettent une solution en valeur.

Une démonstration commerciale montre généralement un chemin favorable. Le jeu de tests doit représenter le travail réel, y compris les cas incomplets, ambigus, contradictoires ou hors périmètre. Il est constitué avant la comparaison, avec des entrées autorisées et des sorties attendues décrites de manière suffisamment précise pour être relues.

Le jeu ne sert pas à produire une note universelle. Il sert à observer des comportements utiles pour cette décision : fidélité aux sources, capacité à signaler un manque, respect d’une consigne, stabilité, traçabilité, temps de vérification et fréquence des escalades. Selon le cas, certaines erreurs sont simplement corrigeables et d’autres imposent l’arrêt immédiat.

Pour éviter une évaluation circulaire, la personne qui prépare les cas et celle qui approuve la décision comparent leurs attentes avant l’essai. Les critères sont écrits sans connaître la réponse de l’outil. L’équipe conserve ensuite les entrées, les sorties, les corrections et la décision humaine dans un journal de test.

Un cas d’usage ne devient pas acceptable parce qu’une majorité de réponses paraît satisfaisante. Une seule erreur critique peut rendre le périmètre inadapté. C’est pourquoi la gravité des erreurs et le comportement attendu en cas d’incertitude comptent autant que la qualité moyenne.

1. Échantillonner le travailRéunir des situations courantes, difficiles et hors périmètre sans introduire de données non autorisées.
2. Décrire l’attenduÉcrire ce qui doit être présent, ce qui doit être absent et ce qui exige une escalade.
3. Figer les conditionsNoter la version des entrées, des instructions, du modèle et des paramètres utiles.
4. Faire relireDemander au responsable métier de juger la sortie selon les critères convenus.
5. Journaliser la décisionConserver la sortie, la correction, la raison de l’acceptation ou du refus et l’action suivante.

5. Transformer la validation humaine en contrôle réel

Ajouter une personne dans le processus ne suffit pas si elle ne sait pas quoi vérifier ou ne peut pas refuser.

La formule « avec validation humaine » est souvent trop vague. Qui valide ? Avec quelles connaissances ? Sur quelles sources ? Dans quel délai ? Peut-on renvoyer le dossier, corriger la sortie, demander une autre analyse ou revenir au mode manuel ? Sans réponses, la validation devient un clic de confirmation.

Le valideur reçoit une grille adaptée au risque. Elle distingue les critères bloquants des critères perfectibles. Pour un brouillon fondé sur des documents, la présence d’une affirmation absente des sources peut être bloquante ; une formulation moins fluide peut rester corrigeable. La grille indique aussi les éléments que le système ne doit jamais inventer, comme une condition commerciale ou une décision réglementaire.

Le NIST AI Risk Management Framework invite à relier le contexte, la finalité, les données, les personnes, les bénéfices, les coûts, la mesure et la gestion des risques sur tout le cycle de vie. Il ne s’agit pas d’une checklist de conformité pour cet article, mais d’un repère utile : gouverner, cartographier, mesurer et gérer restent des activités continues, y compris après le pilote.

La personne qui valide doit disposer du temps et des informations nécessaires. Si le contrôle prend plus d’effort que le processus actuel, ce constat fait partie du résultat. Il peut conduire à réduire le périmètre, améliorer les sources, changer le workflow ou arrêter l’essai.

6. Comparer le coût complet, pas seulement l’abonnement

La facture du fournisseur ne représente qu’une partie du coût du cas d’usage.

Le coût complet commence avant l’achat : cadrage, préparation des données, nettoyage des documents, rédaction des règles, création du jeu de tests et revue des droits. Il continue avec l’intégration, la gestion des accès, la formation des utilisateurs, la validation des sorties, le traitement des exceptions et le suivi des changements.

Il faut aussi estimer le coût de sortie. Une organisation peut devoir exporter ses données, remplacer un connecteur, réécrire une procédure, former de nouveau l’équipe ou reprendre manuellement une file de dossiers. Une solution moins chère à l’entrée peut devenir plus coûteuse si elle enferme le processus ou rend les preuves difficiles à récupérer.

Le bon niveau d’analyse n’est pas toujours une projection financière complexe. Une carte des postes de coût, avec un responsable et une méthode de suivi, suffit pour empêcher la comparaison de se réduire au prix mensuel. Les éléments inconnus restent visibles au lieu d’être transformés en économies supposées.

Le consultant IA doit présenter les hypothèses séparément des observations. Un temps prévu pour la vérification n’est pas un temps mesuré. Une intégration annoncée par un éditeur n’est pas une intégration validée dans l’environnement réel. Ces distinctions protègent la décision d’achat.

7. Écrire le droit d’arrêt avant le pilote

Le projet reste réversible lorsque les déclencheurs d’arrêt, le responsable et le mode de secours sont connus.

Un droit d’arrêt n’est pas un aveu d’échec. C’est une règle de gouvernance. Il précise qui peut suspendre le système, pour quels motifs, comment les utilisateurs sont informés et quel processus prend le relais. Les motifs peuvent inclure une erreur critique, une fuite ou un doute sur les données, une dérive répétée, une impossibilité de vérifier, une dépendance indisponible ou une évolution contractuelle non acceptée.

Le cadre européen sur l’IA adopte une approche fondée sur les risques et associe des obligations spécifiques aux systèmes relevant de catégories élevées. La qualification réglementaire dépend du contexte réel ; elle ne se déduit pas d’un simple intitulé de projet. Pour un premier cadrage, le réflexe utile est de documenter la finalité, les personnes concernées, les conséquences, la traçabilité et le chemin d’escalade, puis de demander l’avis compétent lorsque le cas le nécessite.

Le plan de sortie décrit le mode manuel disponible, l’emplacement des documents utiles, la récupération des données, la révocation des accès et la personne qui décide d’une reprise. Il est testé comme les autres éléments du processus. Un plan qui n’existe que sur le papier peut échouer au moment où l’équipe en a besoin.

Le NIST place également les décisions de poursuivre, modifier, désactiver ou remplacer parmi les activités de gestion. Le cadre rappelle ainsi que le maintien d’un système est une décision récurrente, pas la conséquence automatique d’un achat initial.

8. Préparer le transfert interne dès le cadrage

Un prototype n’est utile que si l’équipe comprend son périmètre, ses contrôles et ses dépendances.

Le transfert interne ne se résume pas à une formation sur l’interface. Il couvre la décision métier, les entrées autorisées, les critères de validation, les erreurs critiques, le journal de test, le coût de contrôle, le droit d’arrêt et le plan de sortie. Cette documentation permet à une autre personne de comprendre le processus sans dépendre d’une démonstration orale.

Chaque responsabilité reçoit un titulaire et un relais : propriétaire métier, responsable des données, référent technique, valideur, personne autorisée à suspendre et responsable de la revue. Dans une petite structure, une même personne peut cumuler plusieurs rôles ; le document doit tout de même les distinguer pour éviter les angles morts.

Le consultant remet aussi les éléments qui permettent de reproduire l’évaluation : versions des instructions, cas de test, critères, résultats observés, corrections et décisions. L’organisation peut ainsi challenger le choix, comparer une autre solution ou reprendre le travail si le prestataire n’intervient plus.

Le transfert se termine par une mise en situation. L’équipe traite un cas normal, un cas ambigu, une erreur critique et une indisponibilité. Le but n’est pas de réciter une procédure, mais de vérifier que les personnes savent quand utiliser le système, quand douter et comment arrêter.

• Une fiche de périmètre lisible par les métiers.
• Un registre des données, accès et versions.
• Le jeu de tests et la grille de validation.
• Les procédures d’escalade, de suspension et de retour manuel.
• La carte des dépendances et des postes de coût.
• Un calendrier de revue et un propriétaire de la mise à jour.

9. DÉCIDE et IRSC : deux niveaux de cadrage complémentaires

IRSC aide à comparer des idées ; DÉCIDE approfondit le cas retenu avant la sélection d’un outil.

La méthode IRSC publiée sur WeWorkWeb propose de regarder l’impact, la répétitivité, la sensibilité et le contrôle humain pour comparer des cas. DÉCIDE intervient ensuite : le canvas oblige l’équipe à expliciter la décision, les entrées, les critères, les intervenants, le droit d’arrêt et l’évaluation.

Ces cadres ne constituent ni une norme, ni une certification, ni une preuve de conformité. Ce sont des supports de discussion et de traçabilité. Ils aident à repérer les questions non résolues avant que l’équipe ne consacre du temps à des paramétrages ou à une intégration.

Le canvas DÉCIDE se remplit en atelier avec les personnes qui font le travail et celles qui assument la décision. Les réponses « à voir » sont transformées en actions, responsables et preuves attendues. Si un bloc essentiel reste sans propriétaire, le test est différé ou réduit.

1. ComparerUtiliser IRSC pour distinguer les idées qui semblent testables de celles qui exigent une réduction ou une étude spécialisée.
2. CadrerRemplir DÉCIDE pour le cas retenu sans mentionner de produit dans la première version.
3. TesterConstruire le jeu de tests et observer les sorties avec les personnes responsables.
4. DéciderChoisir d’arrêter, d’adapter ou de poursuivre avant tout engagement plus large.

10. Exemple entièrement synthétique : préparer une note de réunion

Cet exemple pédagogique ne décrit aucun client, aucune mission et aucun résultat obtenu.

Une équipe fictive souhaite préparer une note de réunion interne à partir d’un ordre du jour et de notes rédigées pour l’exercice. Le système envisagé doit regrouper les sujets, signaler les informations manquantes et proposer un brouillon. Le responsable de projet relit les sources, corrige le texte et décide seul si la note peut être diffusée.

Les données de l’exercice sont synthétiques. Aucun enregistrement audio, message personnel, document client ou information confidentielle n’est utilisé. Le cas est volontairement limité : l’outil ne décide ni des responsables, ni des délais, ni des engagements. Toute proposition non soutenue par les notes doit être supprimée ou marquée comme question.

Le jeu de tests comprend des notes complètes, des formulations ambiguës, une contradiction et une demande hors périmètre. L’évaluation observe la fidélité, le signalement des manques, le respect du format et le travail de vérification. Une invention d’engagement ou l’attribution erronée d’une décision déclenche l’arrêt du test.

Le coût complet comprend la préparation des modèles, la revue des droits, la configuration, le contrôle humain, la documentation et le retour au modèle manuel. À la fin, l’équipe fictive ne conclut pas à un déploiement : elle utilise les traces pour décider d’arrêter, de réduire ou de poursuivre l’étude.

11. Choisir l’outil seulement après le cadrage

Le cahier de décision permet de comparer des solutions sur des critères liés au travail réel.

Une fois DÉCIDE rempli, la comparaison des outils devient plus précise. L’équipe peut vérifier les formats acceptés, les conditions de traitement des données, les possibilités d’administration, les journaux disponibles, l’export, la réversibilité, les contrôles d’accès et la capacité à fonctionner sur le jeu de tests.

La comparaison doit conserver les mêmes entrées, critères et rôles. Si une solution exige un changement important du processus, ce changement est documenté comme une hypothèse distincte. L’équipe évite ainsi de réécrire le besoin pour justifier le produit qui a donné la démonstration la plus spectaculaire.

Le résultat du cadrage peut être de ne choisir aucun outil. Il peut aussi conduire à résoudre d’abord un problème documentaire, à former les utilisateurs, à réduire le périmètre ou à demander une expertise juridique ou de sécurité. Cette décision est productive : elle évite de transférer un problème mal défini dans une nouvelle interface.

Quand un test est poursuivi, la décision porte sur un périmètre, une durée de revue, des responsabilités et des conditions d’arrêt. Le produit est remplaçable ; la méthode de décision reste utile pour les évaluations suivantes.

• Comparer les solutions avec le même jeu de tests.
• Vérifier les conditions sur les données et les accès, pas seulement les fonctionnalités.
• Observer le travail de contrôle et les exceptions.
• Tester l’export et le retour au mode manuel.
• Décider explicitement d’arrêter, d’adapter ou de poursuivre.