P7 DCO D

Pilotage du déploiement

La phase P7 marque le passage du PoC ou de la conception élaborée vers une solution déployée en production. À l’issue d’une décision favorable en P6, l’organisation engage les ressources nécessaires à la réalisation industrielle, à l’intégration et à la mise en service. Cette phase mobilise les compétences du DCO D — clarifier le cadre général (D1), piloter le développement (D2), concevoir l’introduction (D3) et gérer le processus d’introduction (D4).

Le rôle de l’AIBS en phase P7 évolue par rapport aux phases précédentes. L’AIBS conserve sa posture d’orchestration, mais celle-ci s’inscrit désormais dans un cadre projet formel mobilisant des ressources significatives sur plusieurs mois. Selon le contexte de l’organisation, la coordination opérationnelle peut être confiée à un chef de projet dédié, l’AIBS conservant la responsabilité métier et la garantie de cohérence avec les exigences cadrées en P3 et la solution conçue en P4. La compétence D2 (piloter le processus de développement) précise que la vérification des résultats intermédiaires relève d’une évaluation métier, sans nécessité d’expertise technique en code ou en pipelines de données.

La phase P7 se distingue également par sa dimension humaine. Le passage en production implique le déploiement auprès d’utilisateurs réels, dans des contextes opérationnels où les marges d’erreur sont réduites. La conduite du changement, la formation des utilisateurs, la gestion des résistances et des inquiétudes deviennent des composantes essentielles. Une solution techniquement réussie mais mal accompagnée échoue à l’adoption ; la rigueur du cadrage P0-P6 ne suffit pas, l’investissement en accompagnement humain est déterminant.

Le livrable principal de la phase est une solution opérationnelle déployée auprès des utilisateurs cibles, avec les processus d’exploitation, de support et de monitoring en place. La phase P7 se conclut par la transition formelle vers l’exploitation (phase P8), avec transfert des responsabilités vers les fonctions appropriées (ICT Service Management, encadrement métier, fonctions de contrôle). La qualité de cette transition conditionne la pérennité de la solution.

Méthode pas-à-pas

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

1. Clarifier et définir le cadre général du projet (compétence D1)

• Établir la charte de projet : objectifs précis, périmètre fonctionnel, exclusions, jalons majeurs, équipe, gouvernance, budget
• Définir les critères de succès du projet : KPIs métier cibles, seuils techniques, indicateurs d’adoption
• Identifier et documenter les risques projet : risques techniques, organisationnels, juridiques, de calendrier
• Convenir des modalités de gouvernance : composition du comité de pilotage, rythme et instances de décision, processus d’arbitrage
• Faire valider la charte par le sponsor et les parties prenantes principales avant lancement opérationnel

2. Constituer l’équipe et définir la matrice de responsabilités

• Confirmer la composition de l’équipe interdisciplinaire issue de P4, avec ajustements selon les besoins de la phase de réalisation
• Mobiliser les ressources complémentaires : chef de projet si distinct de l’AIBS, ressources de développement, ressources de change management, ressources de formation
• Mettre à jour la matrice RACI projet en intégrant les activités de réalisation, de déploiement et de transition vers l’exploitation
• Clarifier la position de l’AIBS : selon les organisations, AIBS et chef de projet peuvent être deux rôles distincts ou cumulés. L’AIBS reste Accountable sur la garantie métier et la cohérence avec les exigences
• Convenir des modalités de collaboration : rythme des réunions, instances de décision, escalade

3. Piloter le processus de développement (compétence D2)

• Mettre en œuvre le plan d’itérations défini en P4, avec ajustements selon les contraintes opérationnelles
• Vérifier les résultats intermédiaires de chaque itération par évaluation métier : conformité aux exigences, qualité fonctionnelle, alignement avec la conception
• Coordonner les spécialistes mobilisés et arbitrer les questions transversales
• Gérer les écarts par rapport au plan : analyses d’impact, propositions d’ajustement, validation par le comité de pilotage
• Communiquer régulièrement aux parties prenantes : démonstrations, points d’avancement, alertes le cas échéant

4. Concevoir l’introduction de la solution (compétence D3)

• Définir la stratégie de déploiement : déploiement complet (big bang), déploiement progressif (par site, par utilisateur, par fonctionnalité), déploiement pilote suivi de généralisation
• Concevoir l’intégration technique avec les systèmes existants : flux de données, interfaces utilisateurs, gestion des accès, articulation avec les processus métier
• Élaborer le plan de conduite du changement : sensibilisation, formation, accompagnement, gestion des résistances
• Préparer les processus d’exploitation : monitoring, support utilisateur, gestion des incidents, escalade, mises à jour
• Définir les critères de mise en production : seuils techniques, validation métier, conformité réglementaire

5. Préparer la conduite du changement

• Cartographier les populations affectées par la solution : utilisateurs directs, encadrement, fonctions support, parties externes
• Pour chaque population, évaluer le niveau de changement induit et les leviers d’engagement
• Construire un plan de communication différencié : messages adaptés aux préoccupations de chaque population, canaux et rythmes appropriés
• Concevoir le dispositif de formation : contenus différenciés selon les rôles, modalités (présentielle, distancielle, mixte), calendrier articulé avec le déploiement
• Identifier et former des relais internes (champions, super-utilisateurs) capables de soutenir l’adoption sur la durée

6. Préparer les processus d’exploitation et de support

• Définir avec l’ICT Service Management les processus de support utilisateur : niveaux de support, modalités de saisine, SLA, escalades
• Établir le dispositif de monitoring : KPIs techniques (disponibilité, latence, erreurs), KPIs métier (usage, performance fonctionnelle), KPIs de conformité
• Préparer le plan de gestion des incidents : catégorisation, procédures de réponse, communication, post-mortem
• Documenter les processus opérationnels : procédures utilisateurs, procédures de support, procédures de retraining, procédures de revue de conformité
• Convenir des responsabilités d’exploitation : équipe ICT, équipe IA dédiée, équipe métier

7. Conduire la mise en production (compétence D4)

• Vérifier la satisfaction des critères de mise en production définis en amont
• Conduire la mise en service technique : bascule des systèmes, ouverture des accès, activation du monitoring
• Activer le dispositif de communication et de formation
• Mettre en place une cellule de support renforcé pendant la période de stabilisation (typiquement deux à six semaines)
• Recueillir les premiers retours utilisateurs et identifier les ajustements rapides à effectuer

8. Mesurer l’adoption et lever les obstacles

• Suivre les KPIs d’adoption : taux d’utilisation effective, fréquence d’usage par utilisateur, taux de complétion des tâches
• Recueillir les retours utilisateurs par enquêtes structurées, sessions de feedback, observation directe
• Identifier les obstacles à l’adoption : ergonomiques, fonctionnels, organisationnels, formationnels
• Mettre en œuvre les actions correctives appropriées : ajustements fonctionnels, sessions de formation complémentaires, accompagnement individualisé
• Communiquer les progrès et les évolutions aux parties prenantes

9. Clôturer le projet et transférer à l’exploitation

• Vérifier l’atteinte des critères de succès définis dans la charte projet
• Conduire le bilan projet : écarts par rapport au plan, enseignements, contributions individuelles
• Documenter les enseignements pour les futurs projets IA de l’organisation
• Formaliser le transfert vers l’exploitation : transfert des responsabilités, des documentations, des accès, des contrats
• Conclure le projet par un événement de clôture associant l’équipe et les parties prenantes principales

Outils — mode d’emploi détaillé

Charte de projet IA

Mode d’emploi :

• Document fondateur du projet, validé en début de phase P7 et tenu à jour tout au long
• Section 1 — Contexte : rappel synthétique de l’historique du projet, des décisions prises en P0-P6, du sponsor et de la gouvernance
• Section 2 — Objectifs : objectifs métier précis, KPIs cibles, indicateurs d’adoption attendus
• Section 3 — Périmètre : ce qui est dans le scope du projet, ce qui est hors-scope explicitement
• Section 4 — Livrables : liste des livrables attendus, par jalon
• Section 5 — Équipe et gouvernance : composition de l’équipe, rôles et responsabilités, instances de pilotage
• Section 6 — Calendrier : jalons majeurs, dates cibles, dépendances
• Section 7 — Budget : répartition par poste, processus de validation des dépenses
• Section 8 — Risques : risques identifiés, mesures d’atténuation, indicateurs de surveillance
• Section 9 — Critères de succès et de clôture : conditions d’achèvement du projet

Variantes : Charte allégée (5-10 pages) pour projets pilotes. Charte étendue (20-30 pages) pour projets stratégiques. Modèles internes selon les organisations.

⚠ Piège classique

Charte rédigée en début de phase puis non mise à jour. Une charte non actualisée perd sa valeur de référence ; une revue trimestrielle est généralement appropriée.

Plan d’itérations en mode opérationnel

Mode d’emploi :

• Évolution du plan d’itérations cadré en P4, désormais opérationnel sur des cycles de réalisation
• Découpage en sprints courts (typiquement 2 à 4 semaines) avec objectifs précis
• Pour chaque sprint : backlog priorisé, équipe mobilisée, livrables attendus, instance de revue
• Démonstration concrète à chaque fin de sprint, avec invitation du sponsor et de représentants des utilisateurs
• Mécanisme de gestion des écarts : modifications du backlog, décisions de scope, escalade au comité de pilotage
• Articulation avec le cadre méthodologique de l’organisation : Scrum, Kanban, SAFe, méthode hybride

Variantes : Mode purement Scrum pour équipes matures. Mode Kanban en flux continu pour projets de long terme. Mode hybride waterfall + sprints pour grandes organisations peu agiles.

⚠ Piège classique

Itérations dégradées en simple jalon de planning, sans démonstration concrète. La vertu de l’itération est l’apprentissage régulier de l’équipe et des parties prenantes.

Plan de conduite du changement (modèle ADKAR)

Mode d’emploi :

• Modèle ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) appliqué à chaque population concernée
• Awareness — conscience : faire connaître le projet, ses objectifs, ses raisons d’être. Canaux : communication interne, événements, présentations
• Desire — désir : susciter l’envie de participer au changement. Leviers : valeur pour l’utilisateur, alignement avec les motivations professionnelles, anticipation des inquiétudes
• Knowledge — connaissance : transmettre les connaissances nécessaires à l’utilisation. Modalités : formation initiale, documentation, FAQ
• Ability — capacité : permettre l’utilisation effective. Modalités : pratique guidée, accompagnement individuel, périodes d’essai
• Reinforcement — renforcement : ancrer l’usage dans la durée. Modalités : retours réguliers, célébration des succès, ajustements continus
• Pour chaque population et chaque étape, définition des actions, des responsables, des indicateurs de progression

Variantes : Modèle de Kotter en 8 étapes pour les transformations majeures. Modèle de Lewin (unfreeze-change-refreeze) pour les contextes simples.

⚠ Piège classique

Investissement déséquilibré privilégiant la formation (Knowledge) au détriment de l’engagement (Desire). La résistance est traitée trop tard, alors qu’elle se prévient en amont par la qualité du Awareness et du Desire.

Plan de formation utilisateurs

Mode d’emploi :

• Cartographie des populations à former : utilisateurs réguliers, utilisateurs occasionnels, encadrement, support, formateurs internes
• Définition des objectifs pédagogiques par population : ce que chaque utilisateur doit savoir, savoir-faire, comprendre
• Conception des contenus différenciés : modules adaptés aux objectifs et aux profils
• Choix des modalités : présentiel pour interactions complexes, distanciel synchrone pour grands volumes, distanciel asynchrone pour révisions, accompagnement individualisé pour les rôles critiques
• Calendrier articulé avec le déploiement : formation initiale juste avant la mise en service, sessions de consolidation après quelques semaines d’usage, formation continue selon les évolutions
• Évaluation de l’efficacité : tests de connaissances, observation de l’usage réel, satisfaction des participants

Variantes : Formation des formateurs internes pour démultiplier la diffusion. Formation par compagnonnage pour rôles très spécialisés. Microlearning pour les rappels en situation.

⚠ Piège classique

Formation positionnée trop en amont du déploiement, oubliée au moment de l’usage effectif. La règle d’usage : formation initiale dans les deux semaines précédant l’usage, suivi à un mois et trois mois.

KPIs d’adoption

Mode d’emploi :

• KPI 1 — Couverture : proportion des utilisateurs cibles ayant activé leur accès à la solution
• KPI 2 — Activité : proportion des utilisateurs ayant utilisé la solution dans les 30 derniers jours
• KPI 3 — Intensité : nombre moyen d’utilisations par utilisateur actif sur la période
• KPI 4 — Complétion : taux de tâches menées à terme par les utilisateurs ayant initié l’usage
• KPI 5 — Performance fonctionnelle : niveau d’atteinte des KPIs métier ciblés
• KPI 6 — Satisfaction : score moyen sur enquêtes utilisateurs (NPS, CSAT)
• Cible courbe d’adoption : montée progressive avec atteinte du plein régime à 3-6 mois selon la complexité
• Surveillance hebdomadaire en phase de stabilisation, puis mensuelle ou trimestrielle

Variantes : Tableau de bord d’adoption intégré au système. Reporting mensuel structuré. Analyses qualitatives complémentaires (interviews, focus groups).

⚠ Piège classique

Mesure de l’usage technique sans mesure de la valeur produite. Une solution utilisée mais inefficace présente des KPIs d’adoption favorables tout en échouant à délivrer son utilité.

Cas type

Bonnes pratiques observées

Recommandations issues de la pratique professionnelle :

• Le passage du PoC ou de la conception élaborée à la production constitue un saut d’échelle significatif. Les ressources, la rigueur de pilotage, l’investissement en accompagnement humain dépassent généralement de manière substantielle ceux des phases précédentes.
• La compétence D2 précise que la vérification des résultats intermédiaires relève d’une évaluation métier, sans nécessité d’expertise technique en code ou pipelines de données. L’AIBS conserve sa posture d’orchestration, sans glisser vers une posture de direction technique.
• La conduite du changement est généralement sous-investie dans les projets IA. Une règle d’usage : pour chaque franc investi dans le développement technique, prévoir un investissement comparable en accompagnement humain (formation, communication, support, ajustements).
• L’identification de relais internes (champions, super-utilisateurs) constitue un levier essentiel d’adoption. Ces relais sont mobilisés dès la phase pilote et deviennent les ambassadeurs naturels de la généralisation.
• Le séquencement formation-déploiement est critique. Une formation conduite trop tôt s’oublie ; une formation conduite trop tard rate la fenêtre d’apprentissage initial. La règle d’usage : formation initiale dans les deux semaines précédant l’usage effectif.
• La phase de stabilisation après mise en service (deux à six semaines) doit faire l’objet d’un dispositif de support renforcé : ressources support sur-allouées, communication réactive, ajustements rapides en cas de difficultés.
• Les KPIs d’adoption (couverture, activité, intensité, complétion) sont à distinguer des KPIs de performance fonctionnelle. Un projet peut afficher une adoption favorable sans atteindre ses KPIs métier ; les deux dimensions sont à surveiller séparément.
• Le transfert vers l’exploitation est une étape à part entière, à préparer dès le début de la phase. Un transfert mal préparé conduit à des solutions orphelines, sans responsable identifié pour les évolutions et le maintien en condition opérationnelle.
• La documentation projet constitue un actif pour l’organisation. Au-delà des livrables techniques, la capitalisation des enseignements (succès, difficultés, contournements) bénéficie aux projets ultérieurs.
• L’AIBS conserve une responsabilité de garantie métier au-delà de la clôture du projet, généralement sur les six à douze premiers mois d’exploitation. Cette responsabilité s’exerce à travers les revues périodiques avec les fonctions d’exploitation.
• Les écarts par rapport au plan initial sont normaux et attendus dans un projet IA. La gestion mature des écarts (analyse d’impact, propositions d’ajustement, validation par le comité de pilotage) prime sur la prétention à exécuter le plan initial à l’identique.
• La célébration des succès intermédiaires entretient l’engagement de l’équipe sur la durée. Les jalons majeurs et les déploiements régionaux méritent une reconnaissance formelle.

Erreurs fréquentes — et leur antidote

❌ Erreur : Sous-investissement en conduite du changement

✓ Antidote : Inscription au budget projet d’une enveloppe explicite pour la conduite du changement, typiquement 15 à 25% du budget total pour les projets IA affectant les pratiques utilisateurs.

❌ Erreur : Formation positionnée plusieurs mois avant l’usage effectif

✓ Antidote : Calendrier de formation aligné avec le déploiement : formation initiale dans les deux semaines précédant l’usage, sessions de consolidation à un mois et trois mois.

❌ Erreur : Absence de dispositif de support renforcé en phase de stabilisation

✓ Antidote : Cellule de support renforcé sur les deux à six premières semaines suivant la mise en service, avec ressources dédiées et processus de saisine simplifié.

❌ Erreur : Pilotage par planning sans démonstrations intermédiaires

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

❌ Erreur : Confusion entre adoption technique et performance fonctionnelle

✓ Antidote : Suivi distinct des KPIs d’adoption (utilisation effective) et des KPIs de performance (atteinte des objectifs métier). Une solution peut être adoptée sans être performante.

❌ Erreur : Transfert vers l’exploitation préparé en fin de projet

✓ Antidote : Préparation du transfert dès le début de la phase P7, avec implication des fonctions d’exploitation dans les comités de pilotage et anticipation des transferts de responsabilité.

❌ Erreur : Cellule projet repliée sur elle-même, peu d’interactions avec les utilisateurs

✓ Antidote : Cycles réguliers d’interaction utilisateurs : démonstrations, sessions de retour, observations directes, focus groups. Un projet IA réussit à proportion de ses interactions avec les utilisateurs.

❌ Erreur : Documentation projet considérée comme une contrainte plutôt qu’un actif

✓ Antidote : Inscription de la documentation comme livrable du projet, avec validation explicite. La documentation alimente les projets ultérieurs et facilite le transfert vers l’exploitation.

❌ Erreur : Écarts par rapport au plan traités comme des défaillances

✓ Antidote : Cadre formalisé de gestion des changements : analyse d’impact, validation par le comité de pilotage, traçabilité des décisions. La gestion mature des écarts est un signe de maturité projet.

FAQ — questions fréquentes

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

La durée varie largement selon la complexité du projet : trois à six mois pour des projets pilotes, six à dix-huit mois pour des déploiements régionaux ou nationaux, dix-huit à trente-six mois pour des transformations majeures. La règle d’usage : la phase P7 représente fréquemment 50 à 70% de la durée totale d’un projet IA.

Comment articuler les rôles d’AIBS et de chef de projet ?

Selon les contextes, deux configurations sont possibles. Configuration 1 — rôles distincts : un chef de projet pilote l’exécution opérationnelle (planning, budget, équipe), l’AIBS conserve la responsabilité métier et la garantie de cohérence. Configuration 2 — rôles cumulés : l’AIBS exerce les deux responsabilités. Le choix dépend de l’ampleur du projet, des compétences de l’AIBS en gestion de projet, et des conventions de l’organisation.

Quelle stratégie de déploiement privilégier ?

Trois stratégies principales coexistent. Big bang : déploiement complet en une seule fois, adapté aux contextes simples ou aux exigences de cohérence forte. Progressif : déploiement par sites, populations ou fonctionnalités, étalé sur plusieurs mois ; adapté à la majorité des projets IA. Pilote-puis-généralisation : déploiement initial sur un périmètre restreint, suivi d’une généralisation après validation ; adapté aux projets à enjeux ou à incertitudes résiduelles.

Comment gérer les résistances utilisateurs identifiées en cours de déploiement ?

Les résistances sont à analyser plutôt que combattues. Les sources les plus fréquentes incluent : peur de la déshumanisation du métier, crainte de la surveillance, doute sur la qualité des décisions automatisées, sentiment de perte de contrôle. La réponse appropriée combine écoute active, ajustement de la solution lorsque pertinent, formation ciblée, et engagement explicite sur les garde-fous (supervision humaine, droit d’appel, transparence).

Quel est le rôle de l’AIBS après le transfert à l’exploitation ?

L’AIBS conserve une responsabilité de garantie métier sur les premiers mois d’exploitation, exercée à travers des revues périodiques (typiquement mensuelles puis trimestrielles) avec les fonctions d’exploitation. Au-delà de la première année, l’AIBS peut conserver un rôle de référent technique pour les évolutions majeures, ou se désengager complètement selon les contextes.

Comment piloter un projet IA en mode agile dans une organisation peu agile ?

Trois leviers permettent l’adaptation. Levier 1 — adoption d’un cadre hybride : sprints internes à l’équipe IA, jalons formels classiques pour la gouvernance globale. Levier 2 — formation préalable des parties prenantes au mode agile et à ses enjeux. Levier 3 — communication renforcée sur les démonstrations régulières comme contre-mesure à l’absence de jalons traditionnels. La transformation du cadre méthodologique global de l’organisation dépasse le périmètre du projet IA.

Quels indicateurs surveiller en priorité pendant la phase de stabilisation ?

Cinq familles d’indicateurs. KPIs techniques : disponibilité, latence, taux d’erreurs. KPIs d’adoption : couverture, activité, complétion. KPIs de support : volume d’incidents, délai de résolution, satisfaction support. KPIs métier : atteinte des objectifs fonctionnels initiaux. Indicateurs qualitatifs : retours utilisateurs, alertes non quantifiées. La surveillance hebdomadaire est appropriée pendant les six premières semaines.

Pour aller plus loin

• « ADKAR : A Model for Change in Business, Government and our Community » — Jeffrey Hiatt (Ouvrage) — Référence sur le modèle ADKAR de conduite du changement
• « Leading Change » — John P. Kotter (Ouvrage) — Modèle des 8 étapes pour les transformations majeures
• PMBOK Guide — Project Management Institute (Référentiel) — Standard international en gestion de projet
• « The Goal » — Eliyahu Goldratt (Ouvrage) — Théorie des contraintes appliquée au pilotage opérationnel
• ITIL 4 Foundation — guides officiels (Référentiel) — Bonnes pratiques de gestion des services IT et de transition vers l’exploitation

Synthèse de la phase

Questions clés à se poser

• Quel cadre projet (objectifs, scope, gouvernance, risques, budget) ?
• Comment piloter les itérations de dev (sans plonger dans le code) ?
• Comment intégrer la solution (technique, processus, formation) ?
• Quelle stratégie de déploiement (big bang, pilote, vagues) ?
• Comment mesurer l’adoption au démarrage ?

Outils mobilisables

• Charte projet / Project canvas
• Plan d’itérations + revues
• Plan de déploiement et formation
• Plan de change management (ADKAR / Kotter)
• KPIs d’adoption

Spécialistes à solliciter

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

• Chef de projet / PMO (si grande organisation)
• Responsable RH / Formation
• Architecte (intégration prod)
• Support / Service desk

Livrable type

Charte projet, plan de déploiement, plan de change management

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

• La gouvernance projet est en place et acceptée ?
• Le plan de déploiement et formation est validé ?
• Les processus d’exploitation et support sont prêts ?

⚠ Piège classique

Sous-investir dans la conduite du changement : la solution marche techniquement mais personne ne l’utilise. La résistance se gère AVANT le déploiement.

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)