P6 DCO C ★ obligatoire examen

Vérification utilité & rentabilité

La phase P6 conclut la séquence d’évaluation de la solution avant la décision d’engagement vers le déploiement. Elle mobilise deux compétences du DCO C : la compétence C5 (vérifier l’utilité et la rentabilité d’une solution basée sur l’IA), obligatoire à l’examen partie 1, et la compétence C6 (élaborer et présenter des bases de décision). À l’issue de cette phase, le sponsor et le comité de pilotage disposent de l’ensemble des éléments nécessaires à la décision de poursuite, de pivot ou d’abandon du projet.

L’utilité et la rentabilité constituent deux dimensions distinctes mais complémentaires. L’utilité interroge la pertinence métier de la solution : la solution résout-elle effectivement le problème identifié, apporte-t-elle un gain mesurable aux utilisateurs et à l’organisation, son adoption attendue est-elle réaliste. La rentabilité interroge la pertinence économique : les bénéfices attendus dépassent-ils les coûts complets de la solution, sur quel horizon, avec quelle marge de sécurité. Une solution peut être utile mais non rentable, ou rentable sur le papier sans utilité réelle ; les deux dimensions doivent être validées séparément.

Le rôle de l’AIBS en P6 consiste à structurer l’évaluation, à mobiliser les compétences appropriées (contrôle de gestion, finance, expertise métier), à intégrer les conclusions dans un raisonnement cohérent et à formuler une recommandation argumentée. Comme pour la phase P5, l’AIBS n’est pas l’expert final sur chaque dimension : la rigueur des calculs financiers relève du contrôle de gestion, la mesure de l’utilité métier relève des utilisateurs et de leurs encadrants. La contribution distinctive de l’AIBS est l’orchestration et la synthèse.

Le livrable principal de la phase est un dossier de décision structuré, intégrant le business case, la synthèse des évaluations P5 et P6, l’analyse des options et la recommandation. Ce dossier est présenté aux décideurs lors d’une instance de validation formelle. La qualité de la présentation conditionne directement la qualité de la décision : un dossier complet mais mal hiérarchisé conduit à des décisions par défaut ou différées.

Méthode pas-à-pas

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

1. Définir les critères d’utilité avec les parties prenantes

• Conduire un atelier avec les utilisateurs cibles, l’encadrement métier et le sponsor
• Identifier les dimensions d’utilité pertinentes : gain de temps, amélioration de la qualité, réduction des erreurs, augmentation du volume traitable, satisfaction utilisateur, valeur stratégique
• Pour chaque dimension, définir des critères d’évaluation observables et si possible mesurables
• Définir les seuils d’acceptabilité : à partir de quel niveau de gain la solution est-elle considérée comme utile
• Documenter les hypothèses d’usage : volumes, fréquences, profils d’utilisateurs, contextes d’utilisation

2. Mesurer l’utilité par observation et tests

• Selon le contexte : tests utilisateurs sur prototype, observation comparative avec et sans la solution, retours qualitatifs structurés, métriques quantitatives sur jeu pilote
• Mobiliser un échantillon représentatif d’utilisateurs cibles pour les tests
• Documenter les retours : verbatim des utilisateurs, mesures objectives, comparaisons avant/après
• Identifier les écarts entre utilité attendue et utilité observée
• Vérifier l’adéquation entre la solution proposée et les pratiques réelles des utilisateurs

3. Définir les critères de rentabilité avec la fonction finance

• Conduire un atelier avec le contrôle de gestion ou le directeur financier
• Définir l’horizon d’évaluation : trois à cinq ans est usuel pour les projets IA
• Définir le taux d’actualisation et les conventions financières applicables dans l’organisation
• Lister les catégories de coûts à inclure : coûts d’investissement (build), coûts d’exploitation (run), coûts de conformité, coûts de retraining, coûts de change management, coûts d’opportunité
• Lister les catégories de bénéfices à inclure : réductions de coûts directes, gains de productivité, augmentations de revenus, évitements de risques, valeur stratégique

4. Établir le coût total de possession (TCO)

• Évaluer les coûts d’investissement : développement, infrastructure initiale, intégration, formation initiale, conformité initiale (DPIA, audits)
• Évaluer les coûts d’exploitation annuels : licences, infrastructure cloud ou on-premise, monitoring, support, maintenance, retraining
• Évaluer les coûts de conformité récurrents : revues périodiques, audits, mise à jour réglementaire, formation continue
• Évaluer les coûts cachés : drift des modèles, migrations, montées de version, gestion des incidents
• Sommer sur l’horizon retenu, en intégrant l’évolution des coûts (montée en charge, optimisations)

5. Évaluer les bénéfices

• Bénéfices quantifiables directs : temps économisé × volume × valorisation horaire, erreurs évitées × coût unitaire d’erreur, ventes additionnelles, réductions de stocks
• Bénéfices quantifiables indirects : amélioration de la satisfaction client, diminution du turnover, amélioration de l’image
• Bénéfices qualitatifs : positionnement stratégique, capacité d’apprentissage organisationnel, base pour projets futurs
• Documenter les hypothèses sous-jacentes à chaque bénéfice : taux d’adoption, courbe d’apprentissage, durée de réalisation
• Présenter une fourchette plutôt qu’une valeur unique pour les bénéfices incertains

6. Calculer les indicateurs de rentabilité

• ROI (retour sur investissement) : (bénéfices cumulés − coûts cumulés) / coûts cumulés, sur l’horizon retenu
• Payback period : durée nécessaire pour que les bénéfices cumulés couvrent les coûts cumulés
• Valeur actuelle nette (NPV) : somme actualisée des flux nets sur l’horizon, au taux d’actualisation retenu
• Taux de rendement interne (TRI) : taux d’actualisation annulant la NPV
• Comparer les indicateurs aux seuils de l’organisation et aux alternatives connues

7. Conduire une analyse de sensibilité

• Identifier les variables d’incertitude majeures : taux d’adoption, valorisation horaire, coûts d’exploitation, durée d’utilisation
• Pour chaque variable clé, tester des scénarios : pessimiste, central, optimiste
• Recalculer les indicateurs de rentabilité dans chaque scénario
• Identifier les seuils de basculement : à partir de quelle valeur la décision changerait-elle
• Documenter la robustesse de la conclusion : la rentabilité est-elle confirmée dans le scénario pessimiste

8. Synthétiser dans un business case

• Document structuré présentant l’évaluation complète : utilité, rentabilité, risques, conditions
• Synthèse exécutive en tête : recommandation, indicateurs clés, conditions principales
• Section utilité : critères, mesures, conclusions
• Section rentabilité : TCO, bénéfices, indicateurs, sensibilité
• Section options : option recommandée, options alternatives, option « ne rien faire »
• Section conditions et risques : conditions de réalisation, risques identifiés, mesures de mitigation
• Annexes : détails des calculs, hypothèses, sources des chiffres

9. Élaborer les bases de décision et recommander

• Synthétiser les conclusions de P5 (faisabilité) et P6 (utilité, rentabilité) dans un dossier de décision
• Formuler une recommandation tranchée : poursuivre, pivoter, abandonner
• Argumenter la recommandation par référence aux critères d’évaluation et aux conclusions de chaque dimension
• Adapter le format au public décideur : note exécutive d’une page pour la décision, dossier complet pour traçabilité
• Préparer les questions probables des décideurs et les éléments de réponse

10. Présenter aux décideurs et faire valider

• Préparer la présentation : durée typique 30 à 60 minutes selon l’enjeu
• Structurer en SCQA : Situation (où en est le projet), Complication (la question à trancher), Question (les options), Answer (la recommandation)
• Laisser un temps significatif au débat et aux questions des décideurs
• Recueillir la décision formelle : engagement, conditions, échéances
• Documenter par compte rendu signé ou validation écrite explicite

Outils — mode d’emploi détaillé

Business case IA

Mode d’emploi :

• Document structuré présentant l’évaluation économique complète du projet
• Synthèse exécutive (1 page) : recommandation, NPV, ROI, payback, conditions principales, risques majeurs
• Section 1 — Contexte et problématique : rappel du cas d’usage, des objectifs et de l’historique
• Section 2 — Solution proposée : synthèse de la solution conçue en P4, principales caractéristiques
• Section 3 — Évaluation de l’utilité : critères, mesures, conclusions
• Section 4 — Évaluation économique : TCO sur horizon retenu, bénéfices, indicateurs de rentabilité
• Section 5 — Analyse de sensibilité : scénarios pessimiste, central, optimiste, seuils de basculement
• Section 6 — Risques et conditions : risques identifiés, mesures d’atténuation, conditions de réalisation
• Section 7 — Recommandation et options : option recommandée, alternatives considérées, justification
• Annexes : hypothèses détaillées, sources des chiffres, calculs

Variantes : Business case court (10-15 pages) pour projets sous 100 KCHF. Business case approfondi (30-50 pages) pour projets stratégiques ou réglementés.

⚠ Piège classique

Business case orienté pour vendre le projet, avec hypothèses optimistes systématiques. La crédibilité, et donc l’utilité du business case pour la décision, repose sur la transparence des hypothèses et l’intégration de scénarios pessimistes.

TCO sur 3-5 ans

Mode d’emploi :

• Tableau structuré présentant les coûts par catégorie et par année, sur l’horizon retenu (typiquement 3 à 5 ans pour l’IA)
• Catégorie 1 — Investissement initial (année 0) : développement, infrastructure, intégration, formation initiale, conformité initiale
• Catégorie 2 — Exploitation récurrente (chaque année) : licences, infrastructure, support, monitoring, maintenance
• Catégorie 3 — Évolution et amélioration : retraining périodique, montées de version, ajustements fonctionnels
• Catégorie 4 — Conformité continue : revues périodiques, audits, formation continue, gestion réglementaire
• Catégorie 5 — Coûts cachés : gestion des incidents, drift, migrations, opportunités
• Inclure les coûts d’opportunité : ressources internes mobilisées non disponibles pour d’autres projets
• Actualiser les flux selon la convention de l’organisation

Variantes : TCO simplifié à 3 ans pour projets pilotes. TCO étendu à 5-7 ans pour projets d’infrastructure pérenne.

⚠ Piège classique

Sous-estimation systématique des coûts récurrents par focalisation sur le coût d’investissement initial. Pour les projets IA, les coûts récurrents (cloud, retraining, conformité) représentent fréquemment 40 à 60% du TCO sur 5 ans.

ROI et payback period

Mode d’emploi :

• ROI cumulé : (bénéfices cumulés − coûts cumulés) / coûts cumulés, exprimé en pourcentage
• ROI annuel moyen : ROI cumulé divisé par le nombre d’années de l’horizon
• Payback period : durée nécessaire pour que les bénéfices cumulés couvrent les coûts cumulés
• Calcul mois par mois pour les projets à montée en charge progressive
• Comparaison aux seuils internes de l’organisation (souvent ROI > 30% ou payback < 3 ans)
• Documenter les hypothèses d’adoption : un ROI suppose que les utilisateurs adoptent la solution au taux prévu

Variantes : Calculs avec et sans actualisation, selon la convention de l’organisation. NPV (Valeur actuelle nette) et TRI (Taux de rendement interne) pour évaluations financières plus rigoureuses.

⚠ Piège classique

Présentation d’un ROI ponctuel sans précision sur l’horizon ni les hypothèses d’adoption. Un ROI de 200% sur 5 ans suppose un cumul, et n’est pas comparable à un ROI annuel.

Analyse de sensibilité

Mode d’emploi :

• Identification des variables d’incertitude majeures : typiquement 3 à 5 variables clés (taux d’adoption, valorisation horaire, coût cloud, durée d’usage, performance modèle)
• Pour chaque variable, définition de trois scénarios : pessimiste (-30 à -50% selon variable), central (estimation principale), optimiste (+30%)
• Recalcul des indicateurs de rentabilité dans chaque scénario
• Identification des seuils de basculement : valeur d’une variable à partir de laquelle la décision changerait
• Représentation graphique : tornado chart présentant l’impact de chaque variable sur l’indicateur principal
• Conclusion : la rentabilité est-elle robuste (confirmée même en scénario pessimiste) ou fragile (dépendante des hypothèses optimistes)

Variantes : Analyse Monte Carlo pour projets complexes : simulation aléatoire sur les distributions de probabilité des variables. Analyse what-if simple pour projets standards.

⚠ Piège classique

Analyse de sensibilité limitée à des variations symétriques de quelques pourcents, sans tester de vrais scénarios pessimistes. Une sensibilité testant ±5% n’identifie pas les risques structurants.

Note de décision exécutive (1-pager)

Mode d’emploi :

• Document d’une page A4, structuré pour permettre une décision en 5 à 10 minutes de lecture
• Section « Contexte » (3-5 lignes) : rappel du projet et de la décision attendue
• Section « Conclusion de l’évaluation » (5-8 lignes) : utilité confirmée, rentabilité, indicateurs clés (ROI, payback)
• Section « Recommandation » (3-5 lignes) : option recommandée, conditions principales
• Section « Risques majeurs » (3-5 lignes) : risques résiduels, mesures d’atténuation
• Section « Décision attendue » (1-2 lignes) : formulation explicite de la décision demandée
• Document à accompagner du dossier détaillé en annexe pour traçabilité

Variantes : Note exécutive en deux pages pour décisions complexes. Note ultra-courte (½ page) pour validations intermédiaires.

⚠ Piège classique

Note diluée par excès de détails techniques ou financiers, perdant son rôle de support de décision rapide. La règle : si la première phrase ne contient pas la recommandation, la note est mal structurée.

Cas type

Bonnes pratiques observées

Recommandations issues de la pratique professionnelle :

• Les compétences C5 et C6 sont obligatoires à l’examen partie 1. La capacité à structurer un business case, à analyser sa sensibilité et à formuler une recommandation tranchée est attendue.
• L’utilité et la rentabilité constituent deux dimensions distinctes. Une solution faisable et utile peut s’avérer non rentable ; une solution rentable sur le papier peut s’avérer non utile dans la pratique. La distinction est attendue dans la présentation.
• Le rôle de l’AIBS est d’orchestrer l’évaluation économique avec la fonction finance, et non de la conduire en autonomie. Les calculs financiers, les conventions d’actualisation, les hypothèses macro relèvent du contrôle de gestion.
• La quantification des bénéfices doit être étayée par des hypothèses explicites et traçables. Un bénéfice non documenté est non défendable face à des décideurs avertis.
• L’analyse de sensibilité distingue les conclusions robustes des conclusions fragiles. Une rentabilité confirmée uniquement dans le scénario optimiste est un signal d’alerte.
• Le scénario pessimiste doit tester de vraies dégradations, pas des variations cosmétiques. Une sensibilité de plus ou moins cinq pour cent n’est pas une analyse de sensibilité crédible.
• Les coûts cachés des projets IA sont systématiquement sous-estimés : retraining périodique, gestion du drift, conformité continue, montées de version. Une majoration prudentielle de 15 à 25% sur les coûts d’exploitation est généralement justifiée.
• Les bénéfices d’adoption doivent intégrer la courbe d’apprentissage : une solution n’atteint son plein potentiel qu’après plusieurs mois d’utilisation. Un calcul de bénéfices supposant une adoption à 100% dès le premier mois est irréaliste.
• La présentation d’une option « ne rien faire » comme scénario de référence force la quantification du coût de l’inaction. Cet exercice est régulièrement attendu par les comités de direction.
• La recommandation finale doit être tranchée. Une recommandation ambiguë (« la solution présente des avantages et des inconvénients ») renvoie la décision à des considérations annexes et affaiblit la position de l’AIBS.
• Une recommandation négative (no-go) ou conditionnelle est un résultat valable. La capacité à recommander d’arrêter un projet est plus précieuse que la promotion systématique.
• Le format du livrable doit être adapté au décideur. Un comité de direction lit la note exécutive d’une page ; le contrôle de gestion examine les annexes financières ; le DPO consulte la section conformité. Tous ces lecteurs doivent trouver l’information appropriée.

Erreurs fréquentes — et leur antidote

❌ Erreur : Confusion entre utilité et rentabilité dans la présentation

✓ Antidote : Sections distinctes dans le business case : utilité (pertinence métier, gain qualitatif et quantitatif pour les utilisateurs), rentabilité (analyse économique chiffrée). Conclusions séparées.

❌ Erreur : TCO limité aux coûts d’investissement initial

✓ Antidote : Inclusion systématique des coûts récurrents (exploitation, conformité, retraining, maintenance) sur l’horizon retenu. Pour l’IA, les coûts récurrents représentent typiquement 40 à 60% du TCO sur 5 ans.

❌ Erreur : Bénéfices chiffrés sans hypothèses explicites

✓ Antidote : Pour chaque bénéfice, documentation des hypothèses sous-jacentes : volumes affectés, taux d’adoption, courbe d’apprentissage, durée d’utilisation, valorisation horaire.

❌ Erreur : Analyse de sensibilité limitée à des variations symétriques minimes

✓ Antidote : Test de scénarios pessimistes réalistes : dégradation de 30 à 50% sur les variables clés. Identification des seuils de basculement de la décision.

❌ Erreur : Présentation d’un ROI sans indication d’horizon

✓ Antidote : Précision systématique de l’horizon (ROI cumulé sur 3 ans, ROI annuel moyen) et des hypothèses d’adoption sous-jacentes.

❌ Erreur : Recommandation ambivalente, renvoyant la décision aux décideurs

✓ Antidote : Recommandation tranchée et argumentée : poursuivre selon l’option X, ou pivoter, ou abandonner. La décision finale appartient aux décideurs, mais l’AIBS doit fournir une recommandation claire.

❌ Erreur : Absence d’option « ne rien faire » comme scénario de référence

✓ Antidote : Inclusion systématique de l’option « status quo » dans l’analyse, avec quantification du coût de l’inaction (continuité des inefficacités, position concurrentielle, dette technique).

❌ Erreur : Business case orienté pour vendre le projet, optimiste sur les bénéfices et minoré sur les coûts

✓ Antidote : Posture de transparence : présentation explicite des incertitudes, des risques résiduels, des limites de l’évaluation. La crédibilité de l’AIBS s’établit sur la durée.

❌ Erreur : Note de décision exécutive surchargée d’informations techniques

✓ Antidote : Une page maximum, structurée pour permettre une décision en 10 minutes. Les détails techniques figurent dans le dossier complet.

❌ Erreur : Sous-estimation des coûts de change management et d’adoption

✓ Antidote : Inclusion explicite des coûts de formation, d’accompagnement, de gestion de la résistance, de communication. Pour les projets IA, ces coûts représentent typiquement 10 à 20% du TCO.

FAQ — questions fréquentes

Quel horizon retenir pour le business case d’un projet IA ?

L’horizon usuel est de trois à cinq ans pour les projets IA, selon le degré de stabilité de la solution et de l’environnement technologique. Un horizon plus long que cinq ans est rarement justifié en raison de l’évolution rapide des technologies. Un horizon plus court que trois ans capture mal les bénéfices de montée en charge.

Comment quantifier des bénéfices qualitatifs (image, satisfaction) ?

Trois approches sont possibles : (1) les présenter sous forme qualitative, sans tentative de chiffrage, en complément des bénéfices quantifiables, (2) les approximer par des proxies mesurables (taux de churn évité, score de satisfaction), (3) recourir à des méthodes d’évaluation contingente. La transparence sur la méthode retenue est essentielle.

Que faire si la rentabilité est positive mais l’utilité limitée ?

Cette situation est un signal d’alerte : la rentabilité affichée pourrait reposer sur des hypothèses d’adoption surestimées. Une révision de l’estimation des bénéfices, intégrant l’utilité observée, est généralement nécessaire avant recommandation.

Comment intégrer l’inflation et les évolutions de coûts cloud dans le TCO ?

Inflation : application d’un taux annuel cohérent avec les conventions de l’organisation (typiquement 2 à 3% en Europe). Coûts cloud : prise en compte des engagements tarifaires connus, intégration d’une marge prudentielle pour les évolutions imprévues, et inclusion d’une revue annuelle des coûts dans les conditions de réalisation.

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

Pour un projet de taille moyenne, la phase représente typiquement quatre à huit semaines. Les facteurs allongeant la durée incluent la complexité de l’évaluation économique, la nécessité de tests utilisateurs étendus, les processus internes de validation par les fonctions finance et conformité.

Comment gérer un sponsor souhaitant accélérer la décision sans business case complet ?

Trois options sont disponibles : (1) produire un business case allégé en deux semaines, en explicitant les zones non investiguées, (2) demander un report de la décision pour produire le dossier complet, (3) si l’urgence est avérée et le risque limité, accepter une décision préliminaire conditionnée à la validation ultérieure du business case complet. Tracer dans tous les cas.

Comment articuler le business case avec une approche agile (livraisons incrémentales) ?

Le business case peut être structuré par incrément : évaluation économique de chaque incrément planifié, avec révision à chaque jalon majeur. La décision en P6 porte alors sur l’engagement vers l’incrément immédiat, avec engagement de revue avant chaque incrément suivant.

Pour aller plus loin

• « The HBR Guide to Building a Business Case » (Guide) — Référence pour la structure et la rédaction de business cases
• « Cost-Benefit Analysis » — Boardman, Greenberg, Vining, Weimer (Ouvrage) — Méthodologie rigoureuse d’analyse coût-bénéfice
• « The Lean Startup » — Eric Ries (Ouvrage) — Concepts d’évaluation par expérimentation et validation
• « Made to Stick » — Chip & Dan Heath (Ouvrage) — Communication des recommandations et bases de décision
• Cloud TCO Calculators — AWS, Azure, GCP (Outils) — Estimateurs officiels pour le calcul des coûts d’infrastructure

Synthèse de la phase

Questions clés à se poser

• Quelle utilité fonctionnelle réelle pour les utilisateurs ?
• Quel ROI / TCO / payback (sur quel horizon) ?
• Quels coûts cachés (run, monitoring, retraining, conformité) ?
• Quelle est la recommandation finale et avec quelles conditions ?
• Comment présenter aux décideurs (forme et niveau) ?

Outils mobilisables

• Business case (coûts/bénéfices, sensibilité)
• TCO sur 3-5 ans
• ROI et payback period
• Tests utilisateurs / mesures d’utilité
• Note de décision exécutive (1-pager)

Spécialistes à solliciter

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

• Contrôle de gestion / Finance (TCO, ROI)
• Métier (utilité réelle, gain processus)
• Architecte (coûts run et scaling)
• DPO (coûts conformité long terme)

Livrable type

Business case + bases de décision pour go/no-go production

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

• Le ROI est calculé avec hypothèses explicites ?
• Les coûts complets (build + run + conformité) sont chiffrés ?
• La décision est claire (go / no-go / pivot) avec conditions ?
• Les décideurs ont validé la recommandation ?

⚠ Piège classique

Business case orienté pour vendre le projet (ROI optimiste, coûts minorés). Une recommandation no-go peut être plus précieuse qu’un go forcé.

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)