P1 DCO B

Identification des opportunités

La phase P1 est le pivot où l’IA cesse d’être un sujet stratégique pour devenir un sujet opérationnel. On quitte la salle du COMEX pour entrer dans les bureaux des métiers : qui fait quoi, comment, avec quels irritants, quelles opportunités. C’est aussi la phase où l’AIBS révèle son talent — ou ses limites — d’écoute et de cadrage.

L’erreur classique en P1 est de partir avec une **solution en tête** (« on va faire un chatbot ») et de chercher où la placer. C’est l’inverse qu’il faut faire : partir des problèmes réels et chercher si l’IA est une bonne réponse — ou pas. Beaucoup d’opportunités identifiées en P1 se révéleront mieux résolues par de la simple automatisation, par un changement de processus, ou par rien du tout. C’est un résultat acceptable.

Le rôle de l’AIBS en P1 est triple : **explorer largement** (pas se contenter des 2-3 cas évidents), **cadrer rigoureusement** (un cas d’usage flou n’est pas un cas d’usage), et **documenter de façon comparable** (pour permettre la priorisation en P2). Le livrable typique de P1 est une **liste de 8-15 cas d’usage** documentés avec assez de précision pour être discutés, mais pas tellement qu’on ait perdu trois mois.

Une caractéristique sous-estimée de P1 : c’est la phase où les utilisateurs métier s’engagent (ou se désengagent). Si vous menez P1 en mode top-down (« je vais leur dire ce qu’on va faire »), vous récolterez du désengagement et des résistances pour toutes les phases suivantes. Si vous menez P1 en co-construction, vous fabriquez en même temps les futurs ambassadeurs du projet.

Méthode pas-à-pas

Voici le déroulé concret de la phase, étape par étape :

1. Délimiter le périmètre

• Choisir un scope traitable : un département, un processus, une ligne métier — pas « toute l’entreprise »
• Définir avec le client interne : qu’est-ce qui est dedans, qu’est-ce qui est hors-scope
• Identifier les frontières : où commence et finit le périmètre étudié
• Hériter du cadre P0 : la stratégie a-t-elle déjà fléché des priorités ?

2. Cartographier le scope (état réel)

• Documenter les processus actuels : ce qu’on fait, comment, avec quels outils, en combien de temps
• Identifier les volumes : combien de transactions/dossiers/clients par jour/semaine/an
• Repérer les irritants : ce qui agace les utilisateurs, ce qui cause des erreurs, ce qui prend trop de temps
• Repérer les opportunités tacites : ce que les utilisateurs aimeraient pouvoir faire mais ne peuvent pas

3. Mener des entretiens utilisateurs (5-15 selon scope)

• Profil mixte : opérationnels (quotidien), encadrants (vue process), experts (vue technique métier)
• Format : 45-60 min en individuel, semi-directif (questions ouvertes + relances)
• Questions clés : quels irritants ? quelles tâches répétitives ? quelles décisions difficiles ? que feriez-vous si vous aviez une baguette magique ?
• Documenter chaque entretien : verbatim + synthèse + irritants/opportunités identifiés
• Trianguler : ne pas s’arrêter au premier consensus apparent

4. Mener un atelier d’idéation collectif (1/2 journée)

• Composition : 8-15 personnes représentatives du scope (mix métiers + IT + RH si pertinent)
• Phase divergente : générer le maximum d’idées sans filtre (How might we, brainwriting, analogies)
• Phase convergente : regrouper, dédupliquer, formaliser
• Output : 15-30 idées brutes à transformer en cas d’usage cadrés

5. Benchmarking sectoriel et inter-sectoriel

• Identifier 3-5 organisations qui ont déployé de l’IA sur des problèmes similaires
• Documenter leur cas : objectif, solution, résultats publiés, conditions de réplicabilité
• Élargir au inter-sectoriel : un cas d’usage logistique peut s’appliquer en banque
• Sources : presse spécialisée, conférences, retours d’expérience publics, contacts direct

6. Cadrer chaque cas d’usage (AI Use Case Canvas)

• Une fiche par cas, format identique pour permettre comparaison
• Nommer le cas (court, parlant)
• Décrire le problème métier (1 paragraphe)
• Identifier les utilisateurs concernés et leur volume
• Esquisser la solution IA imaginée (sans descendre dans la technique)
• Estimer les bénéfices (qualitatifs + quantitatifs si possible)
• Estimer la faisabilité grossière (données dispo ? compétences ? budget ?)
• Lister les risques principaux

7. Valider la liste avec le client interne

• Présenter la liste consolidée (15-30 cas) au sponsor et aux responsables métier
• Recueillir feedback : avez-vous oublié quelque chose ? un cas mal cadré ? un doublon ?
• Itérer si besoin (1-2 itérations max — sinon vous tournez en rond)
• Faire valider formellement la liste comme base pour P2

Outils — mode d’emploi détaillé

Atelier d’idéation / How Might We

Mode d’emploi :

• Préparation 1 semaine avant : envoyer aux participants un brief de 1 page (contexte, objectifs, format)
• Démarrer par 15 min de cadrage commun sur les irritants identifiés
• Reformuler les irritants en questions « How Might We… » (HMW). Ex : « Les déclarations de sinistres prennent trop de temps » → « HMW accélérer le traitement des déclarations de sinistre tout en maintenant la qualité ? »
• Phase divergente (45 min) : brainwriting silencieux puis partage. Tout est accepté, rien n’est jugé.
• Phase convergente (45 min) : regroupement par affinité, élimination des doublons, formulation claire
• Phase priorisation (30 min) : dot voting (chaque participant pose 3 gommettes sur ses 3 idées préférées)
• Clôture : énoncer les 5-8 cas qui ressortent, vérifier le consensus, planifier la suite

Variantes : Version distancielle avec Mural/Miro. Version éclair en 2h pour PME. Version étalée sur 3 ateliers de 2h pour grands groupes.

⚠ Piège classique

L’animateur qui devient juge (« non, ça c’est pas réaliste »). En phase divergente, AUCUN jugement. La crédibilité se construit en phase convergente, pas avant.

AI Use Case Canvas

Mode d’emploi :

• Format : 1 page A4 par cas, 8-10 cases pré-structurées
• Cases standards : Nom du cas, Problème métier, Utilisateurs concernés (et volume), Tâche actuelle (sans IA), Tâche cible (avec IA), Bénéfices attendus, Données nécessaires, Faisabilité estimée (1-5), Risques, Sponsor potentiel
• Remplir TOUTES les cases — un canvas avec des cases vides est un cas mal cadré
• Co-remplir avec un représentant métier — pas seul
• Versionner : v1 après idéation, v2 après benchmarking, v3 validée pour P2

Variantes : Versions existantes : Canvas de Datatonic, Microsoft AI Use Case Canvas, ML Canvas (Louis Dorard) plus technique.

⚠ Piège classique

Canvas trop optimiste sur les bénéfices et trop vague sur les risques. Forcer la quantification, même approximative (« 50 dossiers/jour, 15 min par dossier, 4 personnes »).

Cartographie de processus (BPMN simplifié)

Mode d’emploi :

• Choisir un processus à cartographier (un par cas d’usage potentiel)
• Identifier le déclencheur (événement initial) et la fin (résultat produit)
• Lister les étapes intermédiaires : qui fait quoi, dans quel ordre
• Représenter visuellement (rectangles = activités, losanges = décisions, flèches = enchaînements)
• Repérer les douleurs : étapes lentes, étapes manuelles répétitives, étapes avec erreurs fréquentes, étapes en attente
• Annoter avec des chiffres : durée moyenne par étape, volume traité, taux d’erreur

Variantes : Notation BPMN complète pour grands processus. Version « bonhomme + flèches » pour PME. Outils : Lucidchart, Bizagi, Miro, papier+post-its.

⚠ Piège classique

Cartographier le processus officiel (celui décrit dans la doc) plutôt que le processus réel (celui que les gens font vraiment). TOUJOURS observer ou interroger les opérationnels.

Benchmarking IA sectoriel

Mode d’emploi :

• Identifier 3-5 cas pertinents : concurrents directs, acteurs adjacents, références sectorielles
• Sources : MIT Sloan, HBR, Capgemini Research, McKinsey AI reports, conférences sectorielles, presse spé
• Pour chaque cas : organisation, contexte, problème résolu, solution déployée, résultats publiés, conditions de réplicabilité
• Évaluer la transférabilité à votre contexte : taille comparable ? maturité comparable ? données comparables ?
• Synthétiser en tableau comparatif

Variantes : Pour vous différencier : élargir à des secteurs adjacents (ex : un assureur peut s’inspirer d’un acteur santé sur la détection de fraude).

⚠ Piège classique

Confondre marketing et réalité. Beaucoup de cas IA publiés sont enjolivés. Croiser au moins 2 sources et chercher les retours nuancés.

Stakeholder mapping (vue métier)

Mode d’emploi :

• Lister exhaustivement les parties prenantes : qui sera affecté par les futurs cas IA, en bien ou en mal
• Catégoriser : utilisateurs directs, encadrants, support, IT, RH, juridique, clients externes éventuellement
• Positionner sur 2 axes : pouvoir (capacité à influencer le projet) × intérêt (degré d’implication)
• Définir une stratégie d’engagement par quadrant : informer, consulter, impliquer, co-décider
• Mettre à jour à chaque phase — les positions évoluent

Variantes : Matrice classique 2x2. Versions plus fines : Mendelow’s matrix, Salience model (pouvoir × légitimité × urgence).

⚠ Piège classique

Ne pas inclure les détracteurs probables. Mieux vaut les identifier tôt et les engager que les découvrir en P7 quand ils bloquent le déploiement.

Cas type

Bonnes pratiques observées

Recommandations issues de la pratique professionnelle :

• Il convient de commencer systématiquement par l’observation avant les entretiens. 30 minutes en immersion sur le poste de travail révèlent ce que 3h d’interview ne diraient pas.
• L’irritant exprimé ne coïncide pas systématiquement avec l’irritant réel. Un comptable qui dit « la saisie est lente » peut en fait souffrir d’une mauvaise organisation des dossiers en amont. Une investigation approfondie est nécessaire.
• Il est préférable d’éviter les ateliers d’idéation avec uniquement des managers. Le brainstorming porte alors sur ce que les managers imaginent du quotidien, pas ce que VIVENT les opérationnels.
• Une fiche cas d’usage de qualité tient typiquement sur une page. Une rédaction sur 3 pages, indique probablement le mélange de plusieurs cas distincts.
• L’estimation des volumes est essentielle. « On reçoit beaucoup de demandes » ne suffit pas. La quantification précise s’impose : 10 par jour, 1000 par jour ? Cette différence est structurante pour la priorisation.
• Les cas d’usage trop génériques appellent une vigilance particulière (« un chatbot pour répondre aux clients »). La précision facilite la priorisation.
• L’identification systématique des solutions non-IA : constitue un préalable : pour chaque cas, « est-ce que ça pourrait se résoudre par une simple automatisation, un changement de process, une formation ? » En cas de réponse affirmative, le cas sort du périmètre IA.
• L’identification précoce des cas avec des données sensibles (RH, santé, finance). constitue une bonne pratique, ces cas traversant la phase P5 (faisabilité conformité) plus difficilement.
• Il convient de réserver une place pour les cas « ambitieux mais utiles ». Si l’ensemble des cas se limite à des automatisations sans risque, la valeur stratégique potentielle est manquée.
• L’exhaustivité absolue n’est pas l’objectif visé. 12-15 cas bien cadrés valent mieux que 40 cas survolés.
• Les cas écartés et leur motif sont à documenter. Ces cas peuvent revenir dans 18 mois lorsque le contexte aura évolué.

Erreurs fréquentes — et leur antidote

❌ Erreur : Partir avec une solution en tête (« on va faire un assistant GPT ») et chercher des cas où la placer

✓ Antidote : Inverser : partir des irritants, sélectionner les cas, et seulement à la fin se demander si l’IA est la bonne réponse.

❌ Erreur : Cadrer chaque cas d’usage avec un format différent

✓ Antidote : Format unique (AI Use Case Canvas) pour TOUS les cas, sinon la priorisation en P2 sera impossible (vous comparerez des pommes et des poires).

❌ Erreur : Ne pas distinguer cas IA et cas d’automatisation classique

✓ Antidote : Pour chaque cas, se demander : pourquoi de l’IA et pas une RPA ou un script ? Si la réponse est floue, ce n’est probablement pas un cas IA.

❌ Erreur : Cas d’usage flous sur les utilisateurs (« pour aider les équipes »)

✓ Antidote : Toujours préciser : QUI exactement (rôle, niveau hiérarchique, équipe), COMBIEN (volume utilisateurs), QUAND (fréquence d’usage).

❌ Erreur : Ignorer l’IT/Data dans les entretiens P1

✓ Antidote : L’IT a des informations critiques sur les données disponibles, les contraintes techniques, les projets parallèles. À inclure systématiquement.

❌ Erreur : Atelier d’idéation animé par un manager interne (qui orientera, même sans le vouloir)

✓ Antidote : L’AIBS anime, le manager participe au même titre que les autres. Ou faire animer par un facilitateur externe.

❌ Erreur : Estimer la faisabilité technique seul, sans expert

✓ Antidote : L’estimation grossière peut se faire seul, mais validation par un Data Scientist/architecte avant de cadrer définitivement.

❌ Erreur : Trop de cas (40+) qui rendent P2 ingérable

✓ Antidote : Plafonner à 15 cas en P1. Le tri vient en P2, mais une P1 qui produit 40 cas est mal cadrée à la base.

FAQ — questions fréquentes

Combien de temps prend P1 typiquement ?

4-8 semaines pour un scope départemental, 8-16 semaines pour un scope organisation entière. Au-delà, c’est qu’on n’a pas assez délimité.

Combien de cas d’usage doit-on viser ?

Idéalement 8-15 cas cadrés. En dessous de 5, vous n’avez pas assez exploré. Au-dessus de 20, vous avez sous-cadré ou mélangé scope.

Faut-il toujours faire un atelier d’idéation collectif ?

Très recommandé : il génère des cas qu’aucun entretien individuel ne fait émerger ET il engage les futurs utilisateurs. Si vraiment impossible (équipe distante, agendas saturés), faire des entretiens en binômes croisés.

Comment gérer un sponsor qui veut imposer un cas d’usage en P1 ?

Accepter de l’inclure dans la liste, mais le faire passer par le même cadrage que les autres. Souvent, le cadrage rigoureux révèle ses faiblesses ou le repositionne mieux.

Que faire si on découvre en P1 que le scope défini est mauvais ?

Remonter au sponsor, expliquer ce qu’on a découvert, proposer un re-scoping. Mieux vaut perdre 2 semaines à recadrer que faire 6 mois sur le mauvais scope.

Comment éviter que P1 devienne une étude qui dort dans un tiroir ?

Validation explicite par le sponsor à la fin de P1, engagement formel sur la suite (P2 dans les X semaines), communication aux participants des entretiens (« voici ce qu’on a fait de vos retours »).

Pour aller plus loin

• « Design Thinking for AI Use Cases » — IDEO U (Cours en ligne) — Méthode d’idéation appliquée à l’IA
• « The AI-Powered Enterprise » — Seth Earley (Livre) — Identification de cas d’usage par les processus
• « AI Use Case Canvas » — Datatonic (Template) — Canvas téléchargeable utilisable directement
• Sloan Review Annual AI Cases (Articles) — Référence pour benchmarking inter-sectoriel
• BPMN 2.0 Quick Guide (Documentation) — Notation standard pour cartographier processus

Synthèse de la phase

Questions clés à se poser

• Quel est le scope (processus, département, ligne métier) ?
• Quels sont les irritants et opportunités vus par les utilisateurs métier ?
• Quels cas d’usage existent dans d’autres secteurs (benchmarking) ?
• Quelles dépendances (données, processus, systèmes) à anticiper ?
• L’état réel du scope est-il documenté ?

Outils mobilisables

• Atelier d’idéation / How might we
• Cartographie de processus (BPMN simplifié)
• Benchmarking sectoriel
• Stakeholder mapping métier
• AI Use Case Canvas (1 par cas)

Spécialistes à solliciter

L’AIBS coordonne — il convient de mobiliser les expertises suivantes à cette phase :

• Responsables métier (process owners)
• Utilisateurs finaux
• Business analyst si analyse processus poussée

Livrable type

Liste documentée de cas d’usage IA avec contexte et dépendances

Critères go / no-go pour passer à la phase suivante

• Au moins 5-10 cas d’usage identifiés et documentés ?
• Le scope et l’état réel sont validés avec le client interne ?
• Les dépendances majeures sont identifiées ?

⚠ Piège classique

Se limiter à 1-2 cas évidents sans exploration : on rate les opportunités latérales souvent plus rentables.

Boussole AIBS — Manuel méthodologique non officiel pour le brevet fédéral d’AI Business Specialist.

Sources : Profil de qualification AIBS v15.04.2025 · Annexe directives FAAIB v1.01 · Document modules FAAIB v2.0 · Règlement examen v3.0 (mars 2026)