Toute la boîte à outils
PréparerCanevas≈ 11 min d’utilisation
Canevas — Cadrer un projet IA avant de choisir un outil
Huit cases à remplir en une heure, à deux ou trois. L’outil se choisit après, jamais avant.
Mis à jour le Transform
Comment l’utiliser — Cet outil s’utilise directement sur cette page : parcourez-le à l’écran ou imprimez-la pour la réunion. Aucun fichier à télécharger.
Une idée d’IA arrive presque toujours sous la forme d’un outil : « on pourrait utiliser un chatbot », « il paraît que tel logiciel fait ça très bien ». Ce canevas inverse l’ordre : il oblige à décrire le problème, le résultat attendu et les conditions d’arrêt avant de prononcer le nom d’un outil. Il tient sur une feuille, se remplit à deux ou trois personnes en une session de 90 minutes, et produit un document suffisant pour qu’un comité de direction dise oui, non, ou pas comme ça.
Les seize cases à remplir
Chaque case se remplit en une à trois phrases, jamais en paragraphe. Si une case résiste plus de cinq minutes, c’est le signal que le sujet n’est pas encore mûr pour ce canevas — il faut l’éclaircir avant, pas pendant la session.
Champs du canevas et critères d’une bonne réponse
- Problème métier en une phrase
- Une phrase sans jargon technique ni nom d’outil, du type « nous perdons du temps à… » ou « nous ratons des… ». Une bonne réponse se comprend par quelqu’un qui n’a jamais entendu parler du projet.
- Situation actuelle et coût du statu quo
- Comment le travail se fait aujourd’hui, et ce que coûte le fait de continuer ainsi pendant douze mois — en temps, en erreurs, en occasions manquées. Une bonne réponse chiffre au moins un des trois.
- Résultat attendu mesurable
- L’état visé, formulé comme un changement observable, pas comme une intention. « Diviser par deux le délai de traitement » plutôt que « améliorer le traitement ».
- Indicateur et valeur cible
- Le chiffre précis qui prouvera le résultat, avec son unité et son seuil. Une bonne réponse nomme l’indicateur, sa méthode de calcul et la valeur qui déclenche un jugement de succès.
- Données nécessaires et propriétaire
- La liste des données qui alimenteront le projet et la personne ou l’équipe qui en a la garde aujourd’hui. Une bonne réponse nomme une personne, pas un service.
- Sensibilité des données
- Le niveau de sensibilité des données concernées (publiques, internes, personnelles, confidentielles) et si elles quittent l’entreprise dans le scénario envisagé. Une bonne réponse dit explicitement si des données personnelles ou stratégiques sont en jeu.
- Périmètre inclus / exclu
- Ce que le projet couvre et ce qu’il ne couvre délibérément pas, pour éviter le glissement de périmètre en cours de route. Une bonne réponse cite au moins un cas exclu de façon explicite.
- Utilisateurs concernés
- Qui utilisera concrètement le résultat au quotidien, combien de personnes, et à quelle fréquence. Une bonne réponse distingue les utilisateurs directs des personnes simplement informées.
- Référent métier
- La personne côté métier qui porte la décision de valider ou d’arrêter le pilote, disponible pendant toute sa durée. Une bonne réponse nomme une personne identifiée, pas une fonction vacante.
- Rôle de la supervision humaine
- Ce qu’une personne vérifie ou valide avant que le résultat produit par l’IA n’ait un effet réel, et à quel moment du processus. Une bonne réponse précise le point exact de contrôle, pas une supervision générale et diffuse.
- Budget plafond
- Le montant maximal que l’organisation accepte d’engager pour le pilote, licences et temps interne compris. Une bonne réponse donne un chiffre, même approximatif, plutôt qu’un renvoi à plus tard.
- Durée du pilote
- La période, bornée dans le temps, pendant laquelle le projet reste un essai et non un engagement définitif. Une bonne réponse tient en semaines ou en mois, avec une date de fin fixée dès le départ.
- Critère de succès
- La condition précise qui, si elle est atteinte à la fin du pilote, justifie de continuer. Une bonne réponse reprend l’indicateur et sa valeur cible, sans les reformuler différemment.
- Critère d’arrêt
- La condition précise qui, si elle survient, déclenche l’arrêt du projet sans négociation. Une bonne réponse est écrite avant le lancement, jamais après avoir vu les premiers résultats.
- Risques identifiés
- Les deux ou trois façons les plus probables dont le projet peut mal tourner (données, adoption, dépendance à un fournisseur, effet non désiré sur les utilisateurs). Une bonne réponse évite la liste générique et cite un risque propre à ce projet précis.
- Décision attendue et date
- Ce que le comité doit trancher (lancer, ajuster, refuser) et la date à laquelle cette décision sera prise. Une bonne réponse fixe une date calendaire, pas « bientôt » ou « au prochain comité ».
L’agenda de la session (90 minutes)
| Temps | Séquence | Objectif | Livrable |
|---|---|---|---|
| 10 min | Cadrage de la session | S’accorder sur le fait qu’on cadre un problème, pas un outil. | Règle du jeu partagée. |
| 20 min | Problème, situation actuelle, résultat attendu | Formuler le problème sans jargon et chiffrer le coût du statu quo. | Trois premières cases remplies. |
| 15 min | Indicateur, données et sensibilité | Choisir l’indicateur cible et clarifier ce qu’on a le droit d’utiliser. | Cases indicateur et données remplies. |
| 15 min | Périmètre, utilisateurs, référent, supervision | Border le projet et nommer les personnes responsables. | Quatre cases de gouvernance remplies. |
| 15 min | Budget, durée, critères de succès et d’arrêt | Fixer les limites du pilote avant de le lancer. | Quatre cases de cadrage du pilote remplies. |
| 10 min | Risques et décision attendue | Nommer ce qui peut mal tourner et fixer la date de décision. | Canevas complet. |
| 5 min | Relecture et vérification | Relire le canevas à voix haute et vérifier la check-list de complétude. | Document validé pour transmission. |
Participants, rôles et éléments à apporter
| Participant | Rôle dans la session | À apporter |
|---|---|---|
| Référent métier | Décrit le problème et la situation actuelle, valide le résultat attendu. | Un exemple concret et récent du problème vécu. |
| Responsable du budget ou de la décision | Fixe le plafond budgétaire et la date de décision. | Une idée du budget disponible pour un pilote. |
| Interlocuteur données ou IT | Éclaire la disponibilité, la qualité et la sensibilité des données. | La connaissance des systèmes qui hébergent ces données. |
| Animateur | Tient le temps, fait respecter l’ordre des cases, note sans reformuler. | Une copie vierge du canevas et une horloge visible. |
Le déroulé de la session
- Poser la règle : aucun nom d’outil ne sera prononcé avant la dernière case remplie — si un outil est déjà mentionné, le noter à part pour plus tard.
- Remplir les cases dans l’ordre du canevas, sans sauter une case difficile : une case laissée vide révèle souvent le vrai point de blocage du projet.
- Faire reformuler chaque case par une personne qui ne l’a pas écrite, pour vérifier qu’elle se comprend sans connaître le contexte oral de la discussion.
- Chiffrer systématiquement ce qui peut l’être — coût du statu quo, budget, durée, indicateur — plutôt que de laisser une formulation qualitative.
- Terminer par une relecture complète à voix haute, du début à la fin, avant de passer à la check-list de complétude.
Le canevas est complet si…
- Le problème est formulé sans nommer aucune technologie ni aucun outil.
- Au moins un des trois éléments du coût du statu quo est chiffré.
- L’indicateur cible a une unité, une méthode de calcul et une valeur seuil.
- Le propriétaire des données et leur niveau de sensibilité sont nommés explicitement.
- Le périmètre exclu contient au moins un cas concret.
- Le référent métier et le point de supervision humaine sont des personnes ou des étapes identifiées, pas des intentions générales.
- Le critère de succès et le critère d’arrêt sont écrits avant tout lancement, avec des seuils différents et non ambigus.
- La date de décision figure au calendrier d’au moins une personne présente dans la session.
Après la session : trois issues possibles
Le canevas rempli n’est pas encore une décision — c’est le document qui permet d’en prendre une en connaissance de cause. Trois issues sont légitimes, et l’abandon en fait partie autant que le lancement.
- Décision immédiate : le problème, le résultat et les données sont clairs, le budget est disponible — le comité peut trancher directement à la date prévue, sans étape intermédiaire.
- Pilote encadré : le projet mérite un essai, mais certaines réponses restent incertaines — le pilote se lance avec la durée, le budget et les critères déjà fixés dans le canevas, sans les redéfinir en cours de route.
- Abandon assumé : une case révèle un obstacle structurel (pas de propriétaire des données, pas de référent métier disponible, coût du statu quo trop faible pour justifier l’effort) — le projet s’arrête ici, avec le motif écrit, ce qui évite qu’il ne revienne sous une autre forme sans qu’on ait tiré la leçon.
Erreurs de cadrage fréquentes
- Nommer l’outil avant le problème : la conversation se déplace immédiatement vers « comment ça marche » au lieu de « pourquoi on le ferait ».
- Confondre résultat attendu et fonctionnalité : « avoir un chatbot » n’est pas un résultat, c’est un moyen ; le résultat est ce que le chatbot change concrètement.
- Laisser le critère d’arrêt vague ou absent : sans lui, un pilote décevant se prolonge par inertie plutôt que par décision.
- Sous-estimer la sensibilité des données parce qu’elles semblent « internes » : une donnée interne peut rester personnelle ou stratégique au sens du projet.
- Désigner un référent métier de façade, occupé ailleurs : le pilote avance alors sans arbitrage rapide en cas de blocage.
- Fixer un budget « à voir selon les résultats » : sans plafond initial, le pilote ne peut pas être comparé à son critère de succès en fin de période.
Un projet qui ne tient pas dans ce canevas n’est pas mûr — pas parce que l’idée est mauvaise, mais parce qu’elle n’a pas encore de propriétaire, de mesure ou de limite.
À retenir
- Le canevas se remplit en 90 minutes, à deux ou trois personnes, dans l’ordre imposé — jamais en commençant par le nom d’un outil.
- Seize cases suffisent : problème, situation, résultat, indicateur, données, sensibilité, périmètre, utilisateurs, référent, supervision, budget, durée, critères de succès et d’arrêt, risques, décision.
- Une case vide ou floue est une information : elle signale l’endroit précis où le projet n’est pas encore prêt.
- L’abandon assumé, motivé et écrit est une issue aussi valable que le lancement d’un pilote ou une décision immédiate.
OAKTEAM Score
Situer votre entreprise sur ce sujet
L’évaluation OAKTEAM Score situe votre entreprise en vingt questions et vous rend des priorités écrites.
