Pour une petite structure, une évaluation de préparation à l’IA conduit à lancer, limiter ou arrêter un workflow nommé, pas à produire un score générique de maturité. Examinez la personne responsable, les entrées et l’accès aux données, la limite de décision, l’artefact d’acceptation, le jeu d’évaluation, les permissions, l’escalade, le suivi et le plan de reprise. Classez chaque élément comme présent, partiel ou manquant. Si les preuves permettent un test, choisissez un seul pilote cadré. Écrivez son test d’acceptation et sa condition d’arrêt avant le début du travail.
Cette définition opérationnelle est une méthode éditoriale de Jungle Roots. Le travail formel sur les risques reste une tâche distincte. Le NIST présente son AI Risk Management Framework comme volontaire et destiné à intégrer des considérations de fiabilité dans la conception, le développement, l’utilisation et l’évaluation de l’IA (NIST AI RMF). Microsoft et HBS publient leurs propres dimensions de préparation ; aucun ne fixe un score universel (Microsoft; HBS Online).
Les sources officielles citées sur cette page ont été vérifiées le 16 octobre 2026.
Réalisez une évaluation de préparation à l’IA en suivant un workflow nommé de son événement de départ à son résultat accepté, puis décidez si les preuves permettent un pilote cadré. Suivez cette séquence compacte :
- Nommez le workflow, son événement de départ, sa sortie attendue et la personne responsable.
- Localisez les preuves pour les entrées approuvées, l’accès aux sources, les actions permises, l’acceptation, l’évaluation, les permissions, l’escalade, le suivi et la reprise.
- Marquez chaque élément présent, partiel ou manquant ; consignez son emplacement et toute lacune importante.
- Déterminez quelles décisions restent humaines et quelles actions sont toujours interdites au workflow.
- Définissez un test d’acceptation à partir d’entrées représentatives et de résultats attendus.
- Écrivez la condition d’arrêt et le chemin de reprise sûre.
- Décidez de lancer un pilote cadré, de maintenir le workflow limité ou de l’arrêter.
Le résultat est un registre de décision vérifiable, pas un pourcentage global de l’entreprise. Réévaluez-le lorsqu’une entrée, permission, action, modèle, fournisseur ou condition d’acceptation change de façon importante.
Quel est le verdict éditorial sur les scores de préparation ?
Mon verdict éditorial est qu’un pourcentage de préparation masque les preuves dont l’opérateur a besoin. C’est mon opinion, pas le résultat d’une expérience sur le portfolio, et aucune expérience de ce type n’est revendiquée. Un pourcentage peut fusionner des lacunes très différentes. L’opérateur doit encore savoir si le workflow peut lire une source, qui approuve une action et ce qui se passe lorsque la sortie échoue.
Microsoft précise que son assistant repose sur ses recherches et son travail avec ses clients, identifie cinq moteurs de valeur et pose dix questions avant de proposer une priorité (Microsoft). C’est le modèle de Microsoft. HBS emploie un autre cadre : intention stratégique, fondations data et technologie, personnes et culture, gouvernance et gestion des risques (HBS Online).
Choix éditorial : conservez le score d’un fournisseur comme son résumé. Gardez le dossier de preuves comme registre opérationnel vérifiable.
Un questionnaire ou un outil peut-il déterminer la préparation à l’IA ?
Le questionnaire d’un fournisseur ou d’un outil peut organiser les preuves, mais il ne peut pas prendre les décisions d’exploitation qui établissent la préparation d’un workflow précis. Il peut guider l’échange, regrouper les réponses, révéler des omissions ou appliquer le modèle du fournisseur. Il ne peut ni choisir la personne responsable du workflow, ni vérifier l’accès réel aux sources approuvées, ni valider la limite de décision, ni certifier la sûreté ou la conformité.
Utilisez le questionnaire comme outil de collecte initiale. Conservez ses questions, ses réponses, son modèle, sa date et tout score produit. Vérifiez ensuite les artefacts sous-jacents avec les personnes qui portent le workflow et ses risques. Ne transformez pas le résultat d’un fournisseur en benchmark universel et ne cherchez pas le « meilleur outil IA » avant d’avoir défini le workflow, les lacunes, les permissions, le test d’acceptation et la condition d’arrêt.
L’assistant de préparation de Microsoft est un exemple documenté de modèle fournisseur, pas une certification universelle (Microsoft). Il appartient aux professionnels qualifiés en droit, vie privée, sécurité et métier de déterminer les revues supplémentaires nécessaires au cas d’usage.
Mesurez la préparation en vérifiant des preuves inspectables pour un seul workflow. Nommez-le simplement, par exemple « rédiger une proposition à partir de documents approuvés ». Nommez la personne responsable du résultat. Demandez ensuite les artefacts qui définissent les entrées, les actions permises, les sorties attendues, les tests, les accès et la gestion des échecs.
Utilisez présent seulement si un examinateur peut ouvrir l’artefact ou observer le contrôle. Utilisez partiel si la preuve existe mais laisse une question importante sans réponse. Utilisez manquant lorsque l’équipe dépend de sa mémoire ou d’une intention. Ces libellés appartiennent à la méthode éditoriale de Jungle Roots, pas au NIST.
Le Playbook du NIST propose des actions sous Govern, Map, Measure et Manage et indique que ces suggestions ne forment pas une checklist (NIST AI RMF Playbook). Le dossier ci-dessous reprend cette posture orientée vers des actions vérifiables, sans revendiquer l’approbation du NIST ni garantir un produit.
Règle de mesure : une assurance orale donne du contexte ; un artefact nommé et consultable constitue une preuve.
Quels sont les trois piliers de la préparation à l’IA ?
Les sources autorisées ne définissent pas trois piliers universels de préparation à l’IA (Microsoft; HBS Online). Pour un modèle de travail compact, Jungle Roots propose la valeur du workflow, les preuves d’exploitation et le contrôle responsable. Ce sont des catégories éditoriales, pas une norme.
La valeur du workflow précise la décision ou la sortie servie et son responsable. Les preuves d’exploitation couvrent les données, les entrées, la limite de décision, l’acceptation et l’évaluation. Le contrôle responsable couvre les permissions, l’escalade, le suivi et l’arrêt ou la reprise.
Microsoft nomme stratégie d’entreprise, stratégie technologie et données, stratégie et expérience IA, organisation et culture, et gouvernance et sécurité de l’IA (Microsoft). HBS regroupe autrement intention stratégique, fondations data et technologie, personnes et culture, gouvernance et risques (HBS Online).
Avertissement : attribuez chaque nombre de piliers à sa source. Ne transformez pas un regroupement éditorial en loi ou consensus.
Quelles preuves mettre dans la grille de préparation ?
La grille doit montrer l’artefact, la question qu’il résout et le statut que le lecteur peut vérifier. La grille ci-dessous est éditoriale. Elle ne vient pas du NIST, de Microsoft, de HBS ou de l’OCDE.
| Élément de preuve | Question à résoudre | Statut éditorial |
|---|
| Workflow nommé | Quel travail précis commence et finit ici ? | Présent / partiel / manquant |
| Responsable | Qui accepte le résultat et porte la décision de risque ? | Présent / partiel / manquant |
| Entrées et données | Quelles sources sont autorisées, disponibles et adaptées ? | Présent / partiel / manquant |
| Limite de décision | Quelles actions sont automatisées et lesquelles restent humaines ? | Présent / partiel / manquant |
| Artefact d’acceptation | Quel fichier, registre ou état prouve la fin du travail ? | Présent / partiel / manquant |
| Jeu d’évaluation | Quelles entrées et sorties attendues testent le workflow ? | Présent / partiel / manquant |
| Permissions | Quelles identités peuvent lire, écrire, approuver ou envoyer ? | Présent / partiel / manquant |
| Escalade | Qui reçoit l’exception et avec quel contexte ? | Présent / partiel / manquant |
| Suivi | Quel registre montre exécutions, erreurs et changements ? | Présent / partiel / manquant |
| Arrêt et reprise | Qu’est-ce qui arrête l’action et restaure un état sûr ? | Présent / partiel / manquant |
La limite de décision doit correspondre aux permissions. L’acceptation doit correspondre au jeu d’évaluation. L’escalade doit correspondre à l’arrêt et à la reprise. En cas de conflit, marquez partiel et notez le conflit au lieu de le masquer.
Demander l’audit des opérations pour faire examiner le dossier avant l’achat d’un outil ou la construction d’un agent.
Évaluez la préparation à l’IA d’un client en demandant les preuves d’un seul workflow nommé, puis remettez-lui un registre de décision qu’il peut vérifier et prendre en charge. Ne déduisez pas la préparation à partir des seuls entretiens et ne présentez pas une méthode éditoriale comme une expérience menée chez un client.
La remise du consultant doit contenir :
- Workflow nommé : le début, la fin, le résultat attendu et la personne responsable.
- Emplacements des preuves : liens ou références vers les artefacts examinés, sans recopier de contenu restreint dans le rapport.
- Statut : présent, partiel ou manquant pour chaque ligne de la grille.
- Lacunes importantes : les faits sans réponse susceptibles de modifier la décision.
- Responsable : la personne chargée de résoudre chaque lacune ou d’accepter la décision résiduelle.
- Prochaine étape autorisée : lancer un pilote cadré, maintenir une limite explicite, recueillir d’autres preuves ou arrêter.
- Test d’acceptation : entrées représentatives, résultats attendus, examinateur et condition de réussite.
- Condition d’arrêt : l’événement ou le résultat qui empêche toute nouvelle action et déclenche la reprise.
- Revues non résolues : toute revue juridique, vie privée, sécurité, achats, accessibilité ou métier encore attendue de professionnels qualifiés.
Terminez la mission en confirmant qui maintient le registre et quels changements importants imposent sa réouverture. Le consultant peut structurer et contester les preuves ; le client reste responsable de nommer les responsables, d’accorder les accès, d’approuver les décisions et d’obtenir les revues exigées par son cas d’usage.
Quelles questions poser dans une évaluation IA ?
Une bonne question demande une décision ou un artefact, pas un oui optimiste. Posez les questions suivantes avec la grille :
- Quel workflow évaluons-nous et qui répond de son résultat ?
- Quelles entrées et sources de données approuvées peut-il utiliser ?
- Quelles décisions peut-il prendre, rédiger ou recommander, et quelles décisions lui sont interdites ?
- Quel artefact prouve l’acceptation et qui le valide ?
- Quels cas couvrent le travail normal, les limites et les sorties inacceptables ?
- Quelle identité et quelle permission autorisent chaque action ?
- Où part une exception et quel contexte l’accompagne ?
- Quel registre permet de lire les exécutions, erreurs et changements ?
- Quelle condition arrête le workflow et comment l’opérateur rétablit-il un état sûr ?
Ces questions sont proposées par Jungle Roots. Le Playbook du NIST reste une source distincte d’actions volontaires de gestion des risques (NIST AI RMF Playbook). Le brief d’automatisation d’un processus métier peut contenir la limite du workflow et les preuves d’acceptation.
Transformez l’évaluation en un seul pilote cadré uniquement si le responsable peut examiner les preuves et appliquer la condition d’arrêt. Suivez cette séquence :
- Nommez le workflow, l’événement de départ, la sortie attendue et la personne responsable.
- Rassemblez les artefacts pour les données, les décisions permises, l’acceptation, l’évaluation, les permissions, l’escalade, le suivi et la reprise.
- Marquez chaque ligne présent, partiel ou manquant et notez l’emplacement de la preuve.
- Définissez le test d’acceptation du pilote à partir du jeu d’évaluation.
- Écrivez la condition qui arrête le pilote ou l’empêche d’exécuter l’action concernée.
- Consignez la décision de lancer, de limiter ou d’arrêter le workflow.
La décision finale dépend de l’organisation et du cas d’usage. Cette grille éditoriale ne délivre aucune certification et ne garantit ni sécurité, ni valeur commerciale. Le NIST décrit son cadre comme volontaire et comme un moyen d’intégrer la fiabilité (NIST AI RMF).
Le cadre de gouvernance IA permet de replacer ce dossier dans les rôles et politiques de l’organisation.
Quels principes d’IA responsable ajouter à la grille ?
Les preuves de préparation ne prouvent pas que les principes d’IA responsable de l’OCDE sont respectés (Principes de l’OCDE sur l’IA). Les principes de l’OCDE couvrent notamment les droits humains et valeurs démocratiques, l’équité et la vie privée, la transparence et l’explicabilité, robustesse, sécurité et sûreté, ainsi que la responsabilité (Principes de l’OCDE sur l’IA). Utilisez-les pour contester le but et les contrôles du workflow. Une grille complète ne prouve pas que chaque principe est respecté.
Le NIST fournit un cadre volontaire de gestion des risques et des actions dans son Playbook (NIST AI RMF; NIST AI RMF Playbook). L’OCDE publie des principes pour une IA digne de confiance (OCDE). Ces sources ne fournissent pas d’évaluation du produit pour le workflow choisi (NIST AI RMF; OCDE).
Limite : utilisez le dossier pour révéler les faits manquants, puis sollicitez les revues juridique, sécurité, vie privée et métier adaptées.
Quelle décision une petite structure doit-elle prendre ensuite ?
Choisissez la prochaine décision pour le workflow nommé : lancer le pilote cadré, maintenir le workflow limité ou l’arrêter. Résolvez les preuves manquantes qui peuvent modifier cette décision avant de comparer d’autres outils. Si le responsable manque, nommez-le. Si la limite est vague, écrivez les actions permises et interdites. Si le jeu d’évaluation n’a pas de résultats attendus, définissez-les avec les personnes capables de juger le travail. Si la reprise est inconnue, empêchez l’action concernée.
C’est une recommandation éditoriale, pas la promesse d’un rendement. Conservez le dossier daté, la décision, les lacunes et leurs responsables. Rouvrez-le lorsqu’une entrée, permission, action, modèle, fournisseur ou condition d’acceptation change de façon importante. Il s’agit d’un déclencheur lié au changement, pas d’une fréquence calendaire inventée.
Demander l’audit des opérations pour transformer un workflow proposé en brief exploitable et vérifiable.
