Cette page n’a pas été pensée comme un exercice théorique. Elle sert à préparer un atelier, un appel fournisseur, un comité de décision ou un premier pilote. Elle complète le guide de gouvernance Agentic AI et se combine bien avec la lecture sur les KPI de pilotage d’un dispositif agentique quand vous voulez aller au-delà du cadrage et déjà préparer la mesure de valeur.
📋 Sommaire
- Pourquoi les projets IA se dérèglent dès le départ
- Questions à poser au sponsor et au métier
- Questions sur la donnée et l’intégration
- Questions sur les risques, la conformité et le contrôle
- Questions à poser à un fournisseur ou intégrateur
- Questions pour préparer un pilote crédible
- Comment utiliser la checklist en réunion de cadrage
- FAQ
Avant d’aller plus loin sur ce sujet
Cette page répond à une question précise. Pour garder une lecture vraiment utile, voici le guide de fond associé et deux compléments qui évitent de perdre du temps sur des articles trop éloignés de votre besoin.
Le fil conducteur à garder en tête :
- commencer par la page qui clarifie le cadre général
- ouvrir ensuite un article plus ciblé sur l’outil, le canal, le KPI ou la décision qui vous bloque
- terminer par une ressource pratique pour transformer la lecture en plan d’action
Pourquoi les projets IA se dérèglent dès le départ
Le scénario classique est connu. Une équipe voit un démonstrateur impressionnant. Le comité de direction demande un “POC rapide”. On pense que la donnée sera simple à connecter. On suppose que les utilisateurs adopteront l’outil “parce qu’il fait gagner du temps”. Puis, trois semaines plus tard, personne n’arrive à dire précisément quelle décision devait être améliorée, quel gain devait être démontré, ni qui arbitre quand les priorités s’entrechoquent.
Dans un environnement B2B, ce défaut de cadrage coûte vite cher. La plupart des projets IA touchent à des processus déjà sensibles : qualification commerciale, support client, rédaction d’offres, analyse documentaire, achats, conformité, connaissance produit. Un cadrage trop large produit des attentes floues. Un cadrage trop technique produit un projet qui parle à l’IT mais pas au métier. Un cadrage trop marketing produit un projet séduisant en démo, mais trop pauvre pour survivre à la réalité.
Un bon cadrage n’est pas un document “joli”. C’est un accord lisible entre un besoin métier, une faisabilité réelle et un mode de contrôle acceptable.
1. Questions à poser au sponsor et au métier
Commencez par les questions qui paraissent les moins “innovantes”. Elles sont pourtant celles qui évitent le plus de faux départs.
Quand ces réponses restent vagues, il ne faut pas passer immédiatement à la démonstration d’un outil. Il faut revenir à la scène métier. Par exemple : “Un commercial perd-il du temps à préparer ses rendez-vous ?”, “Un acheteur lit-il trop lentement des offres complexes ?”, “Une équipe support reformule-t-elle cinquante fois la même réponse ?” Tant que la scène n’est pas formulée, le projet reste trop abstrait.
Sur ce point, la lecture de notre guide sur les clauses SLA pour agents IA peut aussi aider. Elle rappelle qu’un projet sérieux se pense déjà en conditions d’exploitation, pas uniquement en démonstration.
Les 5 éléments qui doivent tenir sur une page
| Élément | Question simple | Signal d’alerte |
|---|---|---|
| Objectif | Qu’est-ce qu’on veut améliorer exactement ? | Objectif formulé comme “faire de l’IA” |
| Périmètre | Quel cas d’usage traite-t-on en premier ? | Projet qui veut couvrir 4 équipes dès le pilote |
| Responsable | Qui décide quand ça bloque ? | Sponsor flou ou partagé entre 3 directions |
| Utilisateur | Qui gagnera concrètement du temps ? | “Tout le monde” comme réponse |
| Valeur | Quel gain observable dans 90 jours ? | Aucune hypothèse de gain mesurable |
2. Questions sur la donnée et l’intégration
La plupart des projets semblent simples tant qu’on ne parle pas des sources réelles. Une donnée “disponible” n’est pas forcément exploitable. Elle peut être dispersée, mal structurée, trop bruitée, juridiquement sensible ou détenue par une équipe qui ne veut pas ouvrir les accès à court terme.
- Quelles sources devront être consultées par la solution : CRM, ERP, documents, FAQ, emails, fiches produit, offres, base contrats, tickets ?
- Qui valide que ces sources sont assez propres pour un pilote ?
- Quel est le niveau de fraîcheur réellement attendu : temps réel, quotidien, hebdomadaire ?
- Quel connecteur ou quelle intégration représente aujourd’hui le vrai goulet d’étranglement ?
- Quels champs sont indispensables dès le départ et quels champs peuvent attendre une phase 2 ?
Il faut aussi distinguer la donnée de démonstration et la donnée de production. Une démo sur 20 documents bien choisis ne dit rien d’un environnement réel où le même cas d’usage devra absorber des exceptions, des documents incomplets, des formulations ambigües et des utilisateurs pressés. Si la donnée est critique, lisez aussi le comparatif sur les SLM et déploiements locaux quand la confidentialité, la latence ou la souveraineté deviennent des critères d’architecture.
3. Questions sur les risques, la conformité et le contrôle
Dans un projet IA B2B, le vrai sujet n’est pas seulement “est-ce que ça marche ?” mais “dans quelles limites accepte-t-on que ça marche ?”. Selon le cas d’usage, il faudra clarifier le niveau d’autonomie accepté, les validations humaines, les logs, l’explicabilité minimale et les règles d’escalade.
Quand le cas d’usage touche des décisions RH, du scoring, de la conformité ou des opérations qui peuvent affecter des personnes physiques, il faut rouvrir la page AI Act pour les PME. Ce n’est pas parce que vous utilisez un modèle “grand public” que le projet échappe automatiquement aux exigences documentaires ou aux obligations de supervision.
Le cadrage doit aussi couvrir le niveau de preuve attendu. Un métier acceptera parfois une réponse à 80 % si elle réduit massivement le temps de préparation, à condition qu’un humain valide avant l’envoi. Dans d’autres contextes, une précision insuffisante rend l’usage inutilisable. Ce seuil doit être formulé avant le pilote, pas après.
4. Questions à poser à un fournisseur ou intégrateur
Un bon fournisseur ne se contente pas de montrer ce que son outil sait faire. Il doit aussi pouvoir dire dans quelles conditions la solution tient, ce qu’elle ne sait pas encore faire, comment elle se surveille, et quels prérequis côté client ne peuvent pas être contournés.
- Quel cas d’usage proche du nôtre avez-vous déjà déployé en conditions réelles ?
- Quelles métriques utilisez-vous pour dire qu’un pilote fonctionne ?
- Quels logs fournissez-vous au client ?
- Comment gérez-vous les mises à jour de modèle, les changements de comportement et les incidents ?
- Quelles dépendances cachées voyez-vous souvent chez vos clients : donnée, sponsor, adoption, sécurité, temps métier ?
- Que doit-on mesurer nous-mêmes pour ne pas dépendre uniquement de vos tableaux de bord ?
Si ces réponses restent vagues, le risque n’est pas seulement technique. Il est aussi commercial : vous risquez d’acheter un discours de solution avant d’avoir clarifié vos propres conditions de réussite.
5. Questions pour préparer un pilote crédible
Le pilote n’a pas besoin d’être grand. Il doit être lisible. L’idée n’est pas d’impressionner un comité ; l’idée est de produire une décision meilleure à la fin du test.
| Question | Bonne réponse | Mauvaise réponse |
|---|---|---|
| Périmètre | Un seul cas d’usage, une équipe, une durée courte | Trois cas d’usage pour “rentabiliser vite” |
| Durée | 4 à 8 semaines avec points d’étape | Pilote sans date de fin claire |
| Mesure | 2 à 4 KPI max, avant / après | Beaucoup d’indicateurs non reliés à une décision |
| Adoption | Utilisateurs identifiés et disponibles | Utilisateurs “à confirmer” |
| Décision finale | Critère explicite pour poursuivre, corriger ou arrêter | “On verra” en fin de test |
Une bonne règle consiste à préparer dès le départ trois scénarios de sortie : continuer tel quel, élargir sous conditions, ou arrêter proprement. Cela oblige à clarifier ce qui comptera réellement au moment du bilan.
6. Comment utiliser cette checklist en réunion de cadrage
Le plus simple est d’organiser un atelier court, dense, avec les bonnes personnes : sponsor, métier, IT, sécurité/compliance si le contexte l’exige, et éventuellement le fournisseur si vous avez déjà une shortlist.
- 10 minutes : reformuler le problème métier en une phrase simple.
- 15 minutes : passer la checklist sponsor / utilisateur / valeur.
- 15 minutes : passer la checklist donnée / intégration / risques.
- 10 minutes : cadrer le pilote : périmètre, métriques, durée, points de revue.
- 10 minutes : lister les inconnues bloquantes et les responsables de résolution.
À la fin, vous devez pouvoir sortir avec une note de cadrage d’une page maximum. Si vous avez besoin de huit pages pour expliquer ce que vous testez, c’est souvent que le cadre n’est pas encore assez net.
Votre plan d’action en 15 minutes
Servez-vous de cette page comme d’un support de travail, pas seulement comme d’une lecture. Cochez ce qui est déjà clair, notez ce qui manque encore et gardez un plan d’action simple.
Pour transformer la lecture en décision
Quand un article devient vraiment utile, il vous aide à choisir la prochaine action. Ces pages complètent la lecture avec un angle plus opérationnel : cas terrain, checklist, cadrage ou accompagnement.
À ce stade, gardez surtout ceci :
- la meilleure suite n’est pas la page la plus longue, mais celle qui vous aide à arbitrer
- les liens ci-dessous restent dans le même dossier pour limiter la dispersion
- ouvrez une seule lecture complémentaire à la fois, puis décidez ce qui doit être testé sur le terrain
FAQ
Guillaume Deplanque
J’utilise ce type de checklist quand un projet IA semble séduisant, mais pas encore assez solide pour être lancé sereinement. Le but n’est pas de freiner : le but est d’éviter de confondre vitesse et clarté.