P3 DCO C

Cadrage besoins & exigences

La phase P3 marque la transition entre l’identification (DCO B) et le développement (DCO C). Le ou les cas d’usage retenus en P2 entrent désormais dans une phase d’approfondissement structuré : il s’agit de transformer une intention de projet en un référentiel de besoins et d’exigences précis, exploitable par les spécialistes qui interviendront en P4 et P5.

Le cadrage des besoins constitue une étape technique exigeante de la démarche AIBS. La compétence C1 (relever et formuler les besoins et les exigences) suppose la capacité à mener une enquête méthodique auprès des parties prenantes, à organiser et hiérarchiser les informations recueillies, et à effectuer la traduction des besoins exprimés en exigences mesurables. Cette traduction est le geste professionnel central de la phase.

La compétence C2 (lancer le processus de développement et de vérification d’une idée) intervient dans la même phase pour ouvrir le terrain technique : analyse de marché des solutions existantes, identification des approches possibles, premières esquisses. Selon les clarifications officielles de l’autorité d’examen, l’analyse de marché demandée en C2 est de nature fonctionnelle (quelles solutions répondent au besoin) et non architecturale (quelles technologies sous-jacentes). L’AIBS sélectionne, n’implémente pas.

Le livrable principal de P3 — généralement un catalogue de besoins assorti d’une liste d’exigences priorisées et d’une analyse de marché des solutions — constitue le point de référence pour toutes les phases suivantes. Une P3 négligée se traduit par des exigences floues qui ne pourront pas être validées en P5, et par des solutions qui ne répondront pas aux attentes en P6.

Méthode pas-à-pas

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

1. Cadrer le périmètre du recueil

• Reprendre le cas d’usage validé en P2 et le formaliser en énoncé de problème
• Délimiter le périmètre fonctionnel (ce qui est dans le scope, ce qui est hors-scope)
• Identifier les contraintes connues (calendrier, budget, conformité, infrastructure)
• Convenir avec le sponsor du livrable attendu et de l’échéance de la phase

2. Cartographier les parties prenantes

• Recenser exhaustivement les parties prenantes : utilisateurs directs, utilisateurs indirects, encadrement, support, IT, DPO, juriste, finance, sponsor
• Pour chaque partie prenante, identifier son intérêt vis-à-vis du projet et son degré d’influence
• Définir une stratégie d’engagement par catégorie : informer, consulter, impliquer, co-décider
• Documenter dans une matrice de stakeholder mapping mise à jour

3. Sélectionner et planifier les méthodes d’enquête

• Choisir les méthodes appropriées selon le contexte : entretiens semi-directifs, observation in situ, ateliers collectifs, sondages quantitatifs, analyse documentaire
• Privilégier la triangulation : combiner au moins deux méthodes pour réduire les biais
• Planifier les sessions : 8 à 15 entretiens pour un projet départemental, 1 à 3 ateliers collectifs, observation sur site selon disponibilité
• Préparer les guides d’entretien et grilles d’observation en amont

4. Mener le recueil des besoins

• Conduire les entretiens et ateliers selon le plan
• Documenter chaque session : verbatim des points clés, synthèse, irritants identifiés, opportunités évoquées
• Pour les besoins non-fonctionnels (performance, sécurité, conformité, éthique), interroger spécifiquement les parties prenantes concernées (DPO, sécurité, métier)
• Trianguler les informations : un besoin exprimé par une seule personne reste à confirmer

5. Établir le catalogue des besoins

• Compiler l’ensemble des besoins recueillis dans un document structuré
• Classer par catégorie : fonctionnels (ce que la solution doit faire), non-fonctionnels (qualité, performance, sécurité), conformité (LPD, AI Act, sectoriel), éthiques (équité, transparence, supervision humaine)
• Pour chaque besoin : description, source (qui l’a exprimé), priorité initiale, traçabilité
• Résumer les messages clés à destination du sponsor et des décideurs

6. Traduire les besoins en exigences

• Pour chaque besoin, formuler une ou plusieurs exigences mesurables
• Une exigence valide est : précise, observable, testable, traçable au besoin source
• Distinguer exigences fonctionnelles (le système doit faire X) et non-fonctionnelles (le système doit être Y)
• Prioriser selon une grille type MoSCoW : Must (indispensable), Should (important), Could (souhaitable), Won’t (exclu de cette version)
• Limiter le nombre de Must pour préserver la priorisation effective

7. Conduire l’analyse de marché des solutions

• Identifier les approches possibles : solutions standard du marché, plateformes SaaS avec IA embarquée, solutions GenAI génériques, développement sur mesure, approches hybrides
• Comparer fonctionnellement : chaque approche couvre-t-elle les exigences Must et Should ?
• Évaluer les dépendances techniques majeures : disponibilité de données, infrastructure requise, compétences nécessaires
• Documenter dans un tableau comparatif sans entrer dans la comparaison architecturale détaillée (qui relève de C3 et des spécialistes)

8. Valider le livrable avec le client interne

• Présenter le catalogue de besoins, la liste d’exigences priorisées et l’analyse de marché au sponsor et aux représentants des parties prenantes
• Recueillir les retours et procéder aux ajustements nécessaires
• Faire valider formellement le livrable comme référentiel pour P4
• Diffuser la version validée aux parties prenantes concernées

Outils — mode d’emploi détaillé

Entretien semi-directif

Mode d’emploi :

• Préparation : guide d’entretien comprenant 8 à 12 questions ouvertes, structurées en thèmes (contexte, pratiques actuelles, irritants, attentes, contraintes)
• Durée recommandée : 45 à 60 minutes par entretien individuel
• Posture de l’enquêteur : questions ouvertes, relances neutres, écoute active, prise de notes synthétique
• Documentation : compte-rendu rédigé dans les 48 heures suivant l’entretien, avec verbatim des points significatifs
• Validation : envoi du compte-rendu à l’interviewé pour vérification factuelle

Variantes : Entretien directif pour besoins de validation factuelle. Entretien collectif (focus group) pour faire émerger des dynamiques de groupe. Entretien d’expert pour les sujets techniques.

⚠ Piège classique

Conduire l’entretien comme un interrogatoire à questions fermées. La richesse du semi-directif vient des questions ouvertes et de la liberté laissée à l’interviewé d’aborder des sujets non anticipés.

Catalogue de besoins structuré

Mode d’emploi :

• Document tabulaire ou base de données comprenant pour chaque besoin : identifiant unique, description, catégorie, source (parties prenantes), priorité initiale, date d’identification, statut
• Catégorisation systématique : fonctionnel, non-fonctionnel, conformité, éthique, transverse
• Traçabilité bidirectionnelle : du besoin vers son origine, et ultérieurement du besoin vers les exigences puis les fonctionnalités développées
• Version contrôlée : une version de référence à chaque jalon du projet

Variantes : Format simple en tableur pour PME (Excel, Google Sheets). Format outillé pour grand compte (Jira, Azure DevOps, IBM DOORS).

⚠ Piège classique

Mélanger besoins (ce que les parties prenantes attendent) et exigences (ce que la solution doit faire). Le catalogue de besoins est l’étape AMONT ; les exigences en sont la traduction structurée.

Liste d’exigences MoSCoW

Mode d’emploi :

• Catégorisation des exigences en quatre niveaux de priorité : Must have (indispensable, sans quoi la solution n’a pas de valeur), Should have (important, contournable temporairement), Could have (souhaitable, à inclure si la capacité le permet), Won’t have (exclu du périmètre actuel)
• Règle de proportions recommandée : maximum 60% en Must, 20% en Should, 20% en Could
• Validation collégiale de la priorisation avec le sponsor et les parties prenantes principales
• Documentation des exigences Won’t have pour les futurs cycles de projet

Variantes : Priorisation numérique 1-5. Méthode Kano (basique, performance, attractif). Priorisation par valeur économique pondérée.

⚠ Piège classique

Sur-représentation des Must par défaut (« tout est indispensable »), qui rend la priorisation inopérante. Forcer la discipline : un projet typique compte 15 à 30 Must, pas 80.

Analyse de marché des solutions IA

Mode d’emploi :

• Identification des approches candidates : 3 à 5 options représentatives (par exemple : solution SaaS établie, plateforme GenAI, développement interne)
• Pour chaque option, évaluation fonctionnelle : couverture des exigences Must et Should, complétude par rapport au catalogue de besoins
• Évaluation des facteurs structurants : conformité (LPD, hébergement, AI Act), dépendances aux fournisseurs, compétences requises, ordre de grandeur des coûts
• Tableau comparatif synthétique présentant les options sur 6 à 10 critères
• Recommandation préliminaire à valider en P4 avec les spécialistes techniques

Variantes : Étude de marché allégée pour PME (3 options). Étude de marché approfondie avec analyse du Magic Quadrant Gartner pour grand compte.

⚠ Piège classique

Glissement vers l’analyse architecturale (comparaison de modèles, de frameworks). Cette analyse relève des spécialistes en P4-P5, pas du périmètre AIBS en P3.

Stakeholder mapping détaillé

Mode d’emploi :

• Recensement exhaustif des parties prenantes affectées par le projet, directement ou indirectement
• Catégorisation par typologie : interne/externe, sponsor/utilisateur/expert/contrôle, individuel/collectif
• Positionnement sur deux axes : pouvoir (capacité à influencer la décision ou l’exécution) × intérêt (degré d’engagement attendu)
• Définition d’une stratégie d’engagement par quadrant : forte autorité + fort intérêt → impliquer ; forte autorité + faible intérêt → satisfaire ; faible autorité + fort intérêt → informer ; faible autorité + faible intérêt → surveiller
• Mise à jour de la cartographie à chaque phase du projet

Variantes : Matrice de Mendelow classique. Modèle Salience (pouvoir × légitimité × urgence) pour stakeholders complexes. RACI étendu pour articulation avec la gouvernance projet.

⚠ Piège classique

Cartographie statique réalisée une seule fois. Les positions des parties prenantes évoluent au cours du projet ; la mise à jour régulière est essentielle.

Cas type

Bonnes pratiques observées

Recommandations issues de la pratique professionnelle :

• La distinction entre besoin (ce que les parties prenantes attendent) et exigence (ce que la solution doit faire) constitue la difficulté centrale de la phase. Cette traduction est le geste professionnel attendu de l’AIBS et fait l’objet d’une attention particulière à l’examen.
• L’observation in situ apporte des informations qui ne ressortent généralement pas des entretiens. Les pratiques réelles diffèrent fréquemment des pratiques déclarées ; les contournements et les bricolages révèlent souvent les vrais irritants.
• La triangulation des sources est essentielle : un besoin exprimé par une seule personne, ou par une seule catégorie de parties prenantes, doit être considéré comme à confirmer.
• L’inclusion précoce du DPO et des fonctions de contrôle (conformité, sécurité, juridique) dans la cartographie des parties prenantes évite les blocages tardifs en phase de faisabilité (P5).
• Les exigences non-fonctionnelles — performance, sécurité, conformité, éthique, accessibilité — sont fréquemment sous-représentées dans les premières versions du catalogue. Une revue spécifique avec les expertises concernées est recommandée.
• La méthode MoSCoW perd son efficacité si la majorité des exigences est classée en Must. Une discipline stricte de priorisation, validée collégialement, préserve la capacité de décision en aval.
• L’analyse de marché en P3 demeure de nature fonctionnelle. La comparaison architecturale détaillée (modèles, frameworks, infrastructure) relève des phases ultérieures et des spécialistes techniques.
• Les exigences Won’t have méritent d’être documentées explicitement. Elles précisent les limites volontaires du périmètre et préviennent les malentendus avec les parties prenantes.
• La traçabilité bidirectionnelle — du besoin vers sa source, et du besoin vers l’exigence — facilite les arbitrages ultérieurs et les justifications en cas d’audit ou de revue de projet.
• La validation formelle du livrable P3 par le sponsor avant entrée en P4 conditionne la qualité de l’ensemble du projet. Une P3 validée sous pression de calendrier produit des dérives en aval.
• Le nombre d’entretiens menés est moins déterminant que leur diversité. Huit entretiens couvrant l’ensemble des typologies de parties prenantes valent davantage que vingt entretiens centrés sur une seule catégorie.
• La quantification des besoins (volumes, fréquences, seuils) facilite la conception de la solution en P4 et la définition des KPIs en P5. Un besoin non quantifié reste difficile à valider.

Erreurs fréquentes — et leur antidote

❌ Erreur : Confusion entre besoin et exigence dans le livrable final

✓ Antidote : Maintenir deux documents distincts ou deux sections clairement séparées : catalogue des besoins (langage des parties prenantes) et liste d’exigences (formulation technique mesurable).

❌ Erreur : Sous-représentation des exigences non-fonctionnelles

✓ Antidote : Conduire des sessions dédiées avec les expertises concernées : DPO pour la protection des données, sécurité pour la résilience, conformité pour les exigences sectorielles, éthique pour la supervision humaine.

❌ Erreur : Priorisation MoSCoW non validée collégialement

✓ Antidote : Soumettre la priorisation initiale à un atelier de validation avec les parties prenantes principales avant figeage du livrable.

❌ Erreur : Analyse de marché glissant vers la comparaison technique détaillée

✓ Antidote : Limiter l’analyse à la dimension fonctionnelle et aux facteurs structurants (conformité, dépendances, ordre de grandeur des coûts). Renvoyer la comparaison architecturale aux spécialistes en P4.

❌ Erreur : Cartographie des parties prenantes incomplète (oubli des fonctions de contrôle)

✓ Antidote : Vérifier systématiquement la présence de quatre catégories : utilisateurs, encadrement, support technique, fonctions de contrôle (DPO, conformité, juridique, sécurité, audit).

❌ Erreur : Recueil des besoins fondé exclusivement sur des entretiens

✓ Antidote : Combiner au minimum deux méthodes : entretiens et observation, ou entretiens et analyse documentaire, ou entretiens et atelier collectif.

❌ Erreur : Besoins non quantifiés (volumes, délais, seuils)

✓ Antidote : Pour chaque besoin significatif, intégrer une dimension quantitative dans la formulation des exigences associées (volumes, fréquences, temps de réponse, taux d’erreur acceptable).

❌ Erreur : Validation tardive du livrable, après entrée en P4

✓ Antidote : Validation formelle du livrable P3 avant ouverture des travaux de P4. Toute évolution ultérieure passe par un processus de gestion des changements.

FAQ — questions fréquentes

Quelle est la durée typique d’une phase P3 ?

Pour un projet départemental avec 10 à 15 entretiens, la phase représente généralement 4 à 8 semaines. Pour un projet à périmètre transversal, la durée peut atteindre 12 à 16 semaines. Une P3 conduite en moins de trois semaines présente un risque élevé de besoins non identifiés.

Comment gérer un sponsor souhaitant compresser la phase ?

Il convient d’expliciter les risques d’un cadrage incomplet (besoins manquants détectés en P5 ou P6, dérive du périmètre, exigences de conformité découvertes tardivement). Une P3 allégée — typiquement par réduction du nombre d’entretiens et concentration sur les parties prenantes critiques — peut constituer un compromis acceptable, à documenter.

Comment articuler le catalogue de besoins avec les exigences existantes (cahier des charges, normes internes) ?

Les exigences pré-existantes constituent une source documentaire à intégrer dans le catalogue. Une analyse documentaire en début de phase permet d’identifier les exigences déjà formalisées et de concentrer le recueil sur les zones non couvertes.

L’analyse de marché doit-elle inclure des solutions internes existantes ?

Oui. Toute solution existante dans l’organisation susceptible de couvrir tout ou partie du besoin doit être considérée comme une option dans l’analyse de marché. L’extension d’une solution existante peut s’avérer plus pertinente qu’une nouvelle acquisition.

Comment formaliser les exigences éthiques ?

Les exigences éthiques se déclinent en exigences mesurables : transparence (capacité à expliquer une décision), équité (absence de biais discriminatoires sur des critères sensibles), supervision humaine (présence d’un humain dans la boucle de décision), réversibilité (possibilité d’annuler ou de contester une décision automatisée).

Que faire des besoins identifiés en P3 mais hors-scope ?

Les besoins hors-scope sont documentés dans le catalogue avec mention explicite de leur exclusion. Ils peuvent être reversés au pool de cas d’usage candidats pour les futurs cycles de priorisation (retour en B1).

Comment gérer les besoins contradictoires entre parties prenantes ?

Les contradictions sont documentées et soumises à arbitrage du sponsor. La résolution peut prendre plusieurs formes : choix d’une partie prenante, compromis, scénarios alternatifs, exclusion temporaire avec engagement de traitement ultérieur. La traçabilité de l’arbitrage est essentielle.

Pour aller plus loin

• ISO/IEC/IEEE 29148 — Requirements engineering (Norme) — Référentiel international pour l’ingénierie des exigences
• BABOK Guide — Business Analysis Body of Knowledge (Référentiel) — Cadre de référence pour l’analyse métier
• Volere Requirements Specification Template (Template) — Modèle complet de spécification d’exigences, librement utilisable
• « Mastering the Requirements Process » — Robertson & Robertson (Ouvrage) — Référence sur la méthode Volere
• Loi fédérale sur la protection des données (nLPD) (Réglementation) — Cadre primaire applicable en Suisse pour le traitement de données personnelles

Synthèse de la phase

Questions clés à se poser

• Qui sont toutes les parties prenantes concernées ?
• Quels besoins métier, utilisateurs, conformité ?
• Quelles exigences en découlent (fonctionnelles, techniques, qualité, sécurité, éthiques) ?
• Quelles solutions standard existent sur le marché (build/buy/GenAI) ?
• Quelles dépendances techniques majeures ?

Outils mobilisables

• Stakeholder mapping détaillé
• Interview / atelier / observation
• Catalogue de besoins structuré
• Liste d’exigences (fonctionnelles, non-fonctionnelles, conformité)
• Analyse de marché des solutions (sélection fonctionnelle)

Spécialistes à solliciter

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

• Utilisateurs finaux et métier
• DPO (exigences LPD/RGPD)
• Responsable sécurité
• Architecte (faisabilité technique haut niveau)
• Data engineer (disponibilité données)

Livrable type

Catalogue de besoins + liste d’exigences priorisées + analyse de marché solutions

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

• Toutes les parties prenantes ont été consultées ?
• Les exigences sont mesurables et priorisées (MoSCoW ou équivalent) ?
• La conformité (LPD, secteur) est intégrée dès l’origine ?

⚠ Piège classique

Confondre besoins (ce que veut l’utilisateur) et exigences (ce que doit faire la solution). Le passage des uns aux autres est un travail de l’AIBS.

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)