P4 DCO C ★ obligatoire examen

Conception solution & équipe

La phase P4 correspond au passage du catalogue d’exigences à une solution concrète. Cette phase mobilise la compétence C3 (développer des solutions basées sur l’IA), qui constitue la compétence la plus emblématique du métier d’AIBS et l’une des quatre compétences obligatoires à l’examen partie 1.

Le terme « développer » employé dans l’intitulé de la compétence ne désigne pas l’implémentation technique — qui demeure l’apanage des spécialistes — mais l’élaboration d’une solution conceptuelle aboutie. Selon les clarifications officielles de l’autorité d’examen, l’AIBS doit être en mesure d’esquisser une solution autonome en tenant compte des modèles d’IA, technologies et produits standards appropriés, puis de l’approfondir en collaboration avec des spécialistes. La preuve d’un développement concret (POC opérationnel) n’est pas exigée à l’examen ; une conception élaborée accompagnée d’une évaluation de faisabilité et d’utilité est suffisante.

Cette phase est également celle de la constitution de l’équipe interdisciplinaire et de la définition des modalités de collaboration. L’AIBS ne porte pas l’expertise technique sur l’ensemble des dimensions (modèles ML, architecture cloud, ingénierie des données, sécurité, conformité) ; sa contribution consiste à orchestrer l’intervention des spécialistes appropriés et à structurer leurs apports en une solution cohérente. La matrice RACI et les briefs d’experts constituent les outils fondamentaux de cette orchestration.

Le livrable typique de P4 — esquisse de solution documentée selon un canvas reconnu (ML Canvas, AI Canvas), matrice RACI projet, plan d’itérations — pose les fondations des phases de validation (P5 et P6). La qualité de l’esquisse de solution conditionne la pertinence de l’évaluation de faisabilité qui suit immédiatement.

Méthode pas-à-pas

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

1. Reprendre le référentiel d’exigences

• Repartir du livrable P3 validé : catalogue de besoins, liste d’exigences priorisées en MoSCoW, analyse de marché des solutions
• Vérifier la complétude du référentiel et identifier d’éventuelles zones nécessitant un complément avant entrée en conception
• Confirmer la priorisation MoSCoW avec le sponsor : les Must restent les ancrages incontournables de la solution

2. Identifier l’approche IA pertinente

• Évaluer les approches candidates issues de l’analyse de marché P3 au regard des exigences
• Distinguer les grandes familles d’approches : règles métier, machine learning supervisé, machine learning non supervisé, apprentissage par renforcement, modèles génératifs (LLM), approches hybrides
• Sélectionner l’approche la plus adaptée selon les exigences et les contraintes (données disponibles, conformité, infrastructure, compétences)
• Documenter le raisonnement et les hypothèses sous-jacentes au choix

3. Esquisser l’architecture haut niveau

• Représenter de manière schématique les composants de la solution : sources de données, traitements, modèle IA, intégration applicative, interface utilisateur
• Identifier les interfaces avec les systèmes existants
• Caractériser les flux de données : entrants, sortants, traitements intermédiaires
• Cette représentation reste de nature fonctionnelle ; la conception architecturale détaillée relève des spécialistes

4. Caractériser les données nécessaires

• Identifier les sources de données mobilisables : sources internes (CRM, ERP, bases métier), sources externes (open data, fournisseurs), données produites par le projet
• Évaluer la qualité attendue selon le référentiel ALCOA+ : attribuables, lisibles, contemporaines, originales, exactes, complètes, cohérentes, durables, disponibles
• Estimer les volumes nécessaires pour entraînement et utilisation
• Formuler les attentes envers les spécialistes data en termes de préparation, nettoyage, anonymisation

5. Constituer l’équipe interdisciplinaire

• Identifier les profils nécessaires selon l’approche retenue : data scientist ou ML engineer, ingénieur des données, architecte cloud ou infrastructure, développeur d’intégration, DPO, expert métier, sponsor
• Définir le périmètre d’intervention de chaque profil et le volume estimé de sa contribution
• Clarifier les modalités de mobilisation : équipe dédiée, contributions ponctuelles, prestataires externes, mix
• Convenir des modalités de gouvernance de l’équipe : rythme de réunions, instances de décision, escalade

6. Établir la matrice RACI projet

• Lister les activités principales du projet (de la fin de P4 à P8) sous forme de lignes
• Lister les rôles et parties prenantes sous forme de colonnes
• Pour chaque activité, attribuer les responsabilités selon la grille RACI : Responsible (qui exécute), Accountable (qui rend compte, un seul par activité), Consulted (qui est consulté), Informed (qui est informé)
• Faire valider la matrice par chaque rôle concerné avant figeage

7. Préparer les briefs spécialistes

• Pour chaque spécialiste mobilisé, préparer un brief structuré : contexte du projet, question ou livrable attendu, échéance, format de retour, contraintes
• Le brief constitue l’outil principal de l’orchestration : sa qualité détermine la pertinence des contributions reçues
• Documenter les questions ouvertes et les arbitrages à mener par le spécialiste plutôt que de pré-supposer les réponses
• Convenir d’un format de restitution adapté au public final (sponsor, comité de pilotage)

8. Formaliser l’esquisse de solution dans un canvas

• Utiliser un canvas reconnu (ML Canvas, AI Canvas) pour structurer la solution sur une page
• Sections typiques : valeur métier, utilisateurs, sources de données, features ou variables d’entrée, type de problème ML, méthode d’évaluation, intégration, déploiement
• Co-construire avec les spécialistes pour éviter les approximations techniques
• Versionner l’esquisse à chaque itération significative

9. Définir le plan d’itérations

• Découper le développement en itérations courtes (typiquement 2 à 4 semaines)
• Pour chaque itération : objectifs, livrables, instances de revue, critères de validation
• Prévoir des démonstrations concrètes à chaque fin d’itération avec le sponsor et les utilisateurs
• Documenter le plan dans un format adapté au pilotage : Gantt simplifié, roadmap, kanban

10. Présenter et faire valider l’esquisse

• Présenter au sponsor et au comité de pilotage l’esquisse de solution, l’équipe constituée, le RACI, le plan d’itérations
• Recueillir les retours et procéder aux ajustements nécessaires
• Obtenir la validation formelle de l’engagement vers P5 (vérification de faisabilité)
• Communiquer l’esquisse aux parties prenantes concernées

Outils — mode d’emploi détaillé

ML Canvas / AI Canvas

Mode d’emploi :

• Format unique sur une page A3 ou A4, structuré en blocs interdépendants
• Bloc « Proposition de valeur » : quel problème métier la solution résout, pour qui, avec quel bénéfice mesurable
• Bloc « Sources de données » : données d’entraînement, données d’inférence, fréquence de mise à jour
• Bloc « Features » : variables d’entrée du modèle, transformations appliquées, ingénierie des caractéristiques
• Bloc « Méthode ML » : type de problème (classification, régression, génération, détection d’anomalies), famille d’algorithmes envisagés
• Bloc « Évaluation hors ligne » : métriques de performance retenues, jeux de test, baseline de comparaison
• Bloc « Évaluation en production » : KPIs métier, instrumentation, retours utilisateurs
• Bloc « Décisions et actions » : ce que la solution déclenche concrètement à partir de ses prédictions
• Bloc « Intégration et déploiement » : modalités de mise à disposition (API, batch, intégration applicative)

Variantes : ML Canvas de Louis Dorard (orientation technique). AI Canvas de A. Agrawal et al. (orientation business). Canvas adapté à la GenAI pour les projets fondés sur des modèles génératifs.

⚠ Piège classique

Canvas rempli par l’AIBS seul, sans intervention des spécialistes data ou ML. Les blocs techniques (méthode ML, évaluation hors ligne, déploiement) requièrent une co-construction pour être pertinents.

Décision Build / Buy / GenAI

Mode d’emploi :

• Cadre d’arbitrage entre quatre options principales : développement interne (build), acquisition d’une solution standard (buy), utilisation de modèles génératifs via API (GenAI), approche hybride combinant plusieurs options
• Critères d’évaluation : couverture fonctionnelle des exigences, coût total de possession sur 3 à 5 ans, dépendance aux fournisseurs, contrôle des données, vitesse de mise en œuvre, compétences disponibles ou à acquérir
• Évaluation en équipe avec sponsor, IT, finance, DPO et spécialistes techniques
• Documentation du raisonnement et des hypothèses sous-jacentes
• Réversibilité : prévoir les modalités de sortie ou de migration en cas de changement

Variantes : Cadre Make/Buy classique pour les contextes hors IA. Matrice de souveraineté technologique pour les organisations sensibles aux dépendances.

⚠ Piège classique

Choix par défaut du GenAI en raison de sa visibilité médiatique, sans évaluation rigoureuse des alternatives. Pour les besoins répétitifs à fort volume, une solution standard ou un développement interne peut s’avérer plus économique et plus contrôlable.

Matrice RACI projet IA

Mode d’emploi :

• Tableau à double entrée : activités du projet en lignes, rôles et parties prenantes en colonnes
• Attribution selon quatre catégories : R (Responsible) pour le rôle qui exécute l’activité, A (Accountable) pour le rôle qui rend compte du résultat, C (Consulted) pour les rôles consultés en amont, I (Informed) pour les rôles informés en aval
• Règle fondamentale : un seul A par activité. Plusieurs A diluent la responsabilité
• Granularité adaptée : ni trop fine (RACI ingérable de 200 lignes), ni trop grossière (un seul A pour tout le projet)
• Validation par chaque rôle concerné avant figeage et diffusion

Variantes : RASCI (ajout du rôle Support). DACI pour les contextes décisionnels (Driver, Approver, Contributor, Informed). RAPID pour les processus de décision complexes.

⚠ Piège classique

Position de l’AIBS confondue avec celle du chef de projet IT. Sur les activités de cadrage, conception et validation métier, l’AIBS est généralement Accountable ; sur les activités d’exécution technique, l’AIBS est Consulted ou Informed.

Brief spécialiste structuré

Mode d’emploi :

• Document court (1 à 3 pages) destiné à un expert sollicité ponctuellement
• Section « Contexte » : présentation synthétique du projet et de l’avancement
• Section « Question posée » : formulation précise de la contribution attendue, sous forme de question ou de livrable
• Section « Périmètre » : ce qui est dans le scope de la sollicitation, ce qui ne l’est pas
• Section « Format de réponse attendu » : note, présentation, recommandation, validation
• Section « Échéance et modalités » : date attendue, instance de restitution
• Section « Documentation jointe » : références aux livrables précédents (catalogue de besoins, esquisse de solution)

Variantes : Brief court (½ page) pour des consultations rapides. Brief étendu (5 à 10 pages) pour des expertises approfondies de plusieurs semaines.

⚠ Piège classique

Brief insuffisamment précis, conduisant le spécialiste à interpréter le besoin et à produire une réponse partiellement hors-sujet. La précision du brief est la responsabilité de l’AIBS, non du spécialiste.

Plan d’itérations

Mode d’emploi :

• Découpage temporel en cycles courts, typiquement 2 à 4 semaines
• Pour chaque itération : objectifs précis, livrables attendus, équipe mobilisée, instances de revue
• Inclusion d’une démonstration concrète à chaque fin d’itération, devant les utilisateurs et le sponsor
• Critères de validation explicites pour le passage à l’itération suivante
• Mécanisme de gestion des écarts : ce qui est reporté, ce qui est replanifié, ce qui sort du périmètre

Variantes : Sprint Scrum classique (2 semaines). Cycle long (1 mois) pour les contextes peu agiles. Kanban en flux continu pour les équipes matures.

⚠ Piège classique

Itérations conçues comme des phases waterfall raccourcies, sans démonstration concrète à chaque fin. La vertu pédagogique et politique de l’itération réside dans la démonstration régulière de la progression.

Cas type

Bonnes pratiques observées

Recommandations issues de la pratique professionnelle :

• La compétence C3, obligatoire à l’examen, exige la capacité à esquisser une solution autonome puis à l’approfondir avec des spécialistes. La séquence — esquisse autonome préalable, approfondissement collaboratif ensuite — fait partie de l’évaluation.
• Le rôle de l’AIBS en P4 consiste à orienter et structurer, non à prendre les décisions techniques détaillées. Le choix d’un algorithme spécifique, d’un framework ou d’une infrastructure relève des spécialistes ; l’AIBS valide la cohérence de l’ensemble avec les exigences métier.
• L’analyse de marché de P3 alimente la décision Build/Buy/GenAI de P4. Les options doivent être évaluées sur leur capacité à couvrir les exigences Must, sur le coût total de possession et sur la maîtrise des dépendances.
• Le ML Canvas constitue un livrable attendu à l’examen pour démontrer la maîtrise de la conception. Sa qualité tient moins à l’exhaustivité qu’à la cohérence entre les blocs : la valeur métier doit pouvoir être mesurée par les métriques d’évaluation, qui doivent pouvoir être calculées sur les sources de données identifiées.
• La constitution de l’équipe interdisciplinaire mobilise systématiquement quatre familles de compétences : données (collecte, qualité), modélisation (choix algorithme, entraînement), infrastructure (hébergement, intégration), conformité (DPO, juridique). L’absence d’une de ces familles est un signal d’alerte.
• La matrice RACI projet IA présente une particularité : l’AIBS est généralement Accountable sur la plupart des activités de cadrage et de validation, alors qu’il/elle n’est Responsible que sur quelques activités spécifiques. Cette distinction est régulièrement testée à l’examen.
• Les briefs d’experts produits en P4 ne sont pas des documents annexes. Ils constituent l’outil principal de l’orchestration et démontrent la capacité de l’AIBS à formuler précisément les attentes envers les spécialistes.
• Le plan d’itérations doit prévoir des démonstrations concrètes à chaque fin de cycle, et non uniquement à la fin du projet. L’apprentissage collectif entre l’équipe et les utilisateurs s’effectue à travers ces démonstrations.
• L’évaluation de la qualité des données selon le référentiel ALCOA+ relève typiquement de la phase P4 et conditionne directement la faisabilité technique évaluée en P5. Une évaluation négligée se traduit par des reprises coûteuses ultérieurement.
• La distinction entre l’esquisse de solution (livrable AIBS) et la spécification technique détaillée (livrable des spécialistes) est essentielle. L’AIBS produit la première, valide la cohérence de la seconde, mais n’est pas l’auteur de l’architecture détaillée.
• La phase P4 peut s’achever sans engagement formel de réalisation d’un POC. Selon les clarifications officielles de l’autorité d’examen, une conception élaborée accompagnée d’évaluations en P5 et P6 constitue un livrable suffisant pour l’examen.
• L’articulation entre P4 et P5 est continue plutôt que séquentielle. Les premiers travaux de faisabilité (P5) peuvent commencer avant la finalisation complète de l’esquisse (P4), à condition que les éléments structurants soient stabilisés.

Erreurs fréquentes — et leur antidote

❌ Erreur : Choix de l’approche IA fondé sur la visibilité médiatique plutôt que sur l’analyse des exigences

✓ Antidote : Documenter explicitement les critères de choix entre les approches candidates et faire valider le raisonnement par le sponsor et un spécialiste technique.

❌ Erreur : ML Canvas rempli par l’AIBS seul, sans intervention des spécialistes

✓ Antidote : Co-construction systématique avec un data scientist ou ML engineer, sur au minimum deux ateliers dédiés.

❌ Erreur : Matrice RACI attribuant à l’AIBS la position Responsible sur les activités d’exécution technique

✓ Antidote : Revue de la matrice avec un spécialiste de la gouvernance projet. L’AIBS est Accountable sur le cadrage et la validation métier, Consulted ou Informed sur l’exécution technique.

❌ Erreur : Brief spécialiste sous forme d’instruction directe (« faites ceci »)

✓ Antidote : Reformulation sous forme de question ouverte ou de livrable attendu, laissant au spécialiste la liberté du chemin technique.

❌ Erreur : Architecture haut niveau conçue sans concertation avec l’équipe IT existante

✓ Antidote : Inclusion systématique d’un architecte d’entreprise ou IT dans la conception haut niveau, pour vérifier la cohérence avec le système d’information existant.

❌ Erreur : Plan d’itérations sans démonstration intermédiaire au sponsor

✓ Antidote : Inscription d’une démonstration concrète à la fin de chaque itération, avec invitation explicite du sponsor et de représentants des utilisateurs.

❌ Erreur : Évaluation des données limitée à la disponibilité, sans évaluation de la qualité

✓ Antidote : Évaluation systématique selon le référentiel ALCOA+ : Attributable, Lisible, Contemporaine, Originale, Exacte, Complète, Cohérente, Durable, Disponible.

❌ Erreur : Engagement irréversible vers une approche unique avant la phase de faisabilité

✓ Antidote : Maintien d’une option de repli identifiée dans l’esquisse, à activer en cas de faisabilité négative en P5.

FAQ — questions fréquentes

Un POC est-il nécessaire pour valider la phase P4 ?

Non, ni à l’examen ni dans la pratique professionnelle générale. Selon les clarifications officielles, une conception élaborée accompagnée d’évaluations de faisabilité et d’utilité est suffisante. Un POC peut néanmoins être pertinent dans certains contextes, notamment pour des approches ou des données nouvelles dans l’organisation.

Comment choisir entre une approche GenAI et une approche ML classique ?

Le choix dépend de la nature du problème (génération de contenu vs. prédiction structurée), du volume et de la nature des données disponibles, des exigences de coût et de latence, et de la maîtrise requise sur le comportement de la solution. Les approches GenAI offrent généralement une mise en œuvre rapide mais une moindre maîtrise sur les sorties ; les approches ML classiques offrent une maîtrise plus fine au prix d’un investissement initial supérieur.

Quelle est la profondeur attendue dans l’esquisse de solution à l’examen ?

Le niveau attendu est celui d’une compréhension conceptuelle suffisante pour orienter les spécialistes et valider leurs propositions. La maîtrise du fonctionnement interne d’un algorithme spécifique n’est pas requise ; la capacité à situer l’approche dans le paysage des approches IA et à argumenter le choix l’est.

Comment dimensionner l’équipe interdisciplinaire ?

Le dimensionnement dépend de l’ampleur du projet. Une équipe minimale comprend un data scientist, un data engineer, un développeur d’intégration et un expert métier, soit quatre profils. Une équipe étendue inclut un architecte, un DPO, un expert sécurité et plusieurs experts métier, soit huit à dix profils. La règle de bonne pratique est d’inclure les quatre familles de compétences : données, modélisation, infrastructure, conformité.

Comment articuler P4 avec une équipe agile existante ?

Le plan d’itérations P4 peut s’inscrire dans le cadre méthodologique existant de l’organisation (Scrum, Kanban, SAFe). L’AIBS adapte son livrable au format en vigueur tout en préservant les invariants : démonstrations régulières, validation par le sponsor, traçabilité des décisions.

Quel canvas privilégier entre ML Canvas et AI Canvas ?

Le ML Canvas (L. Dorard) présente une orientation plus technique, adaptée aux approches de machine learning structuré. L’AI Canvas (Agrawal et al.) présente une orientation plus business, adaptée aux contextes où la valeur métier est le point d’entrée. Les deux canvas peuvent être utilisés en complémentarité : AI Canvas en début de P4 pour cadrer la valeur, ML Canvas en fin de P4 pour cadrer la solution.

Comment gérer l’évolution de l’esquisse de solution au fil des itérations ?

L’esquisse de solution est versionnée à chaque évolution significative. Les modifications structurantes — changement d’approche, modification de l’architecture haut niveau — font l’objet d’une revue formelle avec le sponsor. Les ajustements mineurs sont intégrés dans la version courante.

Pour aller plus loin

• « The ML Canvas » — Louis Dorard (Template et article) — Canvas technique de référence pour les projets de machine learning
• « Prediction Machines » — Agrawal, Gans, Goldfarb (Ouvrage) — AI Canvas et économie de la prédiction
• RACI Matrix Best Practices — PMI (Référentiel) — Standard pour l’établissement des matrices de responsabilités
• ALCOA+ Data Integrity — FDA, EMA (Norme sectorielle) — Cadre de référence applicable à l’évaluation de qualité des données
• « Designing Machine Learning Systems » — Chip Huyen (Ouvrage) — Approche système des projets ML, du cadrage au déploiement

Synthèse de la phase

Questions clés à se poser

• Quelle approche IA (ML supervisé, GenAI, RAG, règles, hybride) ?
• Quelle architecture haut niveau (sources données, traitement, intégration) ?
• Quelle équipe assembler (Data Scientist, Dev, Architecte, DPO, métier) ?
• Comment les rôles et responsabilités sont-ils répartis (RACI) ?
• Quel processus itératif (sprints, revues) ?

Outils mobilisables

• ML Canvas / AI Canvas
• Architecture sketch haut niveau
• RACI projet
• Brief spécialiste (1 par expert sollicité)
• Plan d’itérations

Spécialistes à solliciter

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

• Data Scientist / ML Engineer (choix modèle)
• Architecte / Cloud (intégration, hébergement Suisse si requis)
• Data Engineer (pipeline données)
• Développeur (intégration applicative)
• DPO (validation by design)

Livrable type

Esquisse de solution (Canvas) + RACI équipe + plan d’itérations

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

• L’approche IA est argumentée par rapport aux alternatives ?
• L’équipe est constituée et a accepté son RACI ?
• La gouvernance des données et conformité est cadrée ?

⚠ Piège classique

L’AIBS qui veut tout décider techniquement (« je veux du GPT-4 ») au lieu de poser le besoin et laisser les spécialistes proposer. Rappel : l’AIBS oriente, ne code pas.

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)