Six phases. One operating standard.

Les six phases

Du diagnostic au run, une seule boucle opérationnelle continue.

1. 01

   Diagnostic

   1–3 weeks

   Ce qui casse réellement, et ce que coûte l’inaction.

   Inputs

   • Brief énoncé par le sponsor
   • Stack, fournisseurs, contrats dans le périmètre
   • Périmètre de conformité et de risque
   • Contraintes opérationnelles (équipes, délais, budget)

   Outputs

   • Énoncé du problème reformulé
   • Modes de défaillance et risques de second ordre cartographiés
   • Recommandation go / no-go avec justification
   • Périmètre de mission et validation du partner désigné
2. 02

   Architecture

   2–6 weeks

   La couche d’exploitation conçue avant qu’une seule ligne de code ne soit livrée.

   Inputs

   • Diagnostic memo
   • Architecture de référence par classe de workload
   • Socle réglementaire (EU AI Act, GDPR, DORA, NIS2, HIPAA, MDR)
   • Contraintes des plateformes existantes

   Outputs

   • Document d’architecture opérationnelle (jeu d’ADR)
   • Flux de données, résidence, rétention, posture de chiffrement
   • Routage des modèles et points de contrôle human-in-the-loop
   • Conception de la piste d’audit et politique de kill switch
3. 03

   Build

   8–24 weeks

   Des systèmes de niveau production. Pas des POC.

   Inputs

   • Document d’architecture approuvé
   • Cadence de sprints avec leads seniors désignés
   • Socle de sécurité (moindre privilège, secrets, scans)
   • Socle d’observabilité dès le premier jour

   Outputs

   • Logiciel fonctionnel livré dans les environnements de production
   • Piste d’audit Hikari Blue Ops intégrée
   • SLO définis et instrumentés
   • Runbooks opérateur et ébauche de rotation d’astreinte
4. 04

   Governance

   Continuous

   Des preuves émises par la plateforme elle-même, pas assemblées avant l’audit.

   Inputs

   • Périmètre réglementaire (EU AI Act, articles 12, 14, 15)
   • Clauses d’audit client et avenant DPA
   • Cadre de réponse à incident
   • Liste des sous-traitants ultérieurs et cadence de notification

   Outputs

   • Piste d’audit immuable par workload
   • Points de contrôle human-in-the-loop actifs et testables
   • Kill switch testé chaque trimestre
   • Pack de preuves prêt pour le régulateur, sur demande
5. 05

   Adoption

   Chevauchement avec Build + Run

   L’adoption commence par la clarté, pas par le vernis. Un échec ici et le système n’atteint jamais la production. L’adoption s’enseigne, elle ne se présume pas. Voir les parcours de formation livrés avec cette phase→

   Inputs

   • Observation en situation des workflows utilisateurs
   • Plan de conduite du changement avec sponsors désignés
   • Supports de formation co-écrits avec les opérateurs
   • Journaux de friction issus du déploiement progressif

   Outputs

   • Tableau de bord des signaux d’adoption (usage réel, pas le nombre de sièges)
   • Système d’aide et voie d’escalade en service
   • Champions internes briefés et équipés
   • Backlog d’itération piloté par le signal de friction
6. 06

   Run

   Durée définie ou ouverte

   Run est la phase la plus longue, pas la phase résiduelle. Traitée comme la première.

   Inputs

   • Système de production avec piste d’audit et SLO
   • Rotation d’astreinte follow-the-sun (Austin · Paris · Tokyo)
   • Socle FinOps (coût par workload, par workflow)
   • Contrat de discipline de run avec responsable désigné

   Outputs

   • Revue de run mensuelle avec le partner désigné
   • Actions d’optimisation des coûts, signées et tracées
   • Revues d’incident avec mémos de retour d’expérience
   • Jalon de transfert de propriété défini