Build : De la gouvernance à la réalité système Votre gouvernance projet est opérationnelle, vos équipes sont mobilisées et votre périmètre est verrouillé ? Vous vous demandez comment transformer maintenant votre blueprint en système concret et fonctionnel ? Après avoir structuré votre organisation projet pendant le Démarrage, vous entrez dans la phase BUILD de la méthode PRISM : le moment où vos ateliers de conception deviennent une solution logicielle testée et validée.Dans cet article, découvrez comment piloter cette phase de conception et construction technique qui concentre 40% de votre budget et représente le point de non-retour de votre projet. 🎯 L’essentielLe BUILD se déroule en deux temps : d’abord la conception détaillée (Design), puis la construction technique – vous co-construisez le blueprint avec l’intégrateur avant de lancer la réalisationCette phase suit une logique itérative, pas séquentielle – vous alternez entre ateliers de conception, prototypage avec vos utilisateurs et ajustements continus pour éviter l’effet tunnelVotre responsabilité bascule de la supervision à la validation terrain – vos Key Users deviennent co-concepteurs puis testeurs quotidiens, et c’est leur capacité à manipuler le système qui garantira l’adoption finale Les deux visages du BUILDLe BUILD n’est pas du simple « paramétrage logiciel ». C’est la transformation de vos processus cibles en solution opérationnelle, qui se déroule en deux phases distinctes.Phase 1 – Design/Architecture (4 à 8 semaines) : Vous traduisez vos processus métier en spécifications détaillées lors d’ateliers avec l’intégrateur. Chaque processus est décrit écran par écran, champ par champ. Le livrable : un Blueprint (dossier de spécifications fonctionnelles) qui servira de référence pour la construction.Phase 2 – Construction et Tests (8 à 16 semaines) : L’intégrateur configure le système, développe les spécifiques nécessaires, et vous testez progressivement en conditions réelles. Le livrable : un système fonctionnel, validé par vos utilisateurs, prêt pour le go-live.L’objectif final ? Arriver au go-live avec un système qui répond à trois exigences non-négociables : conformité aux spécifications, stabilité technique sur vos volumes réels, et appropriation par vos équipes. Attention : Le BUILD concentre le plus fort risque de dérapage budgétaire et calendaire. Sans pilotage rigoureux par les indicateurs, chaque jour d’indécision coûte 3 jours de retard au go-live. Les projets qui dérivent de plus de 20% de périmètre pendant cette phase perdent totalement le contrôle. Phase Design : de vos processus au BlueprintAvant de toucher au moindre paramètre dans l’ERP, vous devez d’abord spécifier précisément comment chaque processus va fonctionner dans le nouveau système.Les ateliers de conception fonctionnelleCes ateliers réunissent vos Key Users et les consultants de l’intégrateur. Vous décrivez ensemble, processus par processus, le fonctionnement attendu du système. Exemple Fournisseur d’électricité EnergiePlus : Lors de l’atelier « Facturation et comptabilisation », vos Key Users spécifient comment le système doit générer automatiquement les écritures comptables depuis une facture client : quel compte général débiter (411 Client), quels comptes créditer (707 Ventes + 445 TVA + 447 Taxes énergétiques CSPE/TCFE), et quel workflow de validation appliquer avant comptabilisation définitive. Les questions traitées sont très opérationnelles : Quels champs sont obligatoires ? Qui valide quoi selon quel montant ? Comment gérer les cas particuliers ? Que se passe-t-il en cas d’erreur ?N’oubliez pas : Tout ce qui n’est pas spécifié dans le Blueprint ne sera pas construit. Une règle métier oubliée = une fonctionnalité absente du système. Soyez exhaustifs pendant ces ateliers, car corriger après la construction coûte 10 fois plus cher.Les ateliers d’architecture techniqueEn parallèle, les architectes techniques définissent comment l’ERP s’intègre avec vos autres systèmes et comment structurer vos données. Exemple EnergiePlus : Spécification de l’interface avec la plateforme bancaire : format des fichiers de prélèvement SEPA (XML PAIN.001), fréquence d’envoi (quotidien à 14h), traitement des rejets (alerte automatique + blocage génération suivante), et rapprochement automatique des encaissements avec les factures clients. L’intégrateur identifie également les développements spécifiques nécessaires (RICEFW) : interfaces avec vos systèmes métier, états personnalisés, extensions fonctionnelles que le standard ne couvre pas.Votre rôle pendant le DesignVos Key Users sont les co-concepteurs du système. Ils doivent challenger les propositions de l’intégrateur, arbitrer entre plusieurs options fonctionnelles, et documenter le « pourquoi » de chaque choix.Cette phase dure 4 à 8 semaines et nécessite 60 à 80% du temps de vos Key Users. Si vous la bâclez, vous payerez en rework pendant la construction.Phase Construction : du Blueprint au systèmeUne fois le Blueprint validé, l’intégrateur lance trois chantiers simultanés : la configuration, les développements spécifiques, et les tests progressifs.La configuration du systèmeC’est l’exploitation des capacités natives de l’ERP pour reproduire vos processus. Pas de code, juste de l’intelligence dans les réglages des milliers de paramètres disponibles.Ce qui est configuré : structures organisationnelles (entités, sites, centres de coûts), plan comptable adapté à votre métier, grilles tarifaires, règles de gestion (seuils d’approbation, calculs automatiques), workflows de validation.Exemple EnergiePlus : Configuration du module facturation avec paramétrage des comptes de taxes énergétiques spécifiques (CSPE, TCFE), règles de comptabilisation automatique selon le type de client (B2C, PME, Grandes Entreprises), et schémas d’écriture pour factures d’acompte vs factures de régularisation.Vos Key Users doivent être présents à chaque atelier de configuration pour valider que le paramétrage reproduit bien le Blueprint, et surtout pour apprendre à paramétrer eux-mêmes les tables simples. Cette autonomie est critique pour la suite.Les développements spécifiquesTous les ERP ont des limites. Les développements sur mesure comblent ces trous fonctionnels, mais attention : chaque ligne de code est une dette technique pour les 10 prochaines années.Le modèle RICEFW regroupe 6 catégories : Reports (états personnalisés), Interfaces (connexions avec autres systèmes), Conversions (scripts de migration de données), Extensions (nouvelles fonctionnalités), Forms (écrans adaptés), Workflows (automatisations métier). Exemple EnergiePlus : Développement d’une interface avec la plateforme bancaire pour l’envoi automatique des prélèvements SEPA et le rapprochement des encaissements. Coût initial : 12 jours de développement (18K€). Mais sur 7 ans avec la maintenance annuelle, le coût total atteindra 35K€. Mémo Avant de valider un développement spécifique, posez-vous 3 questions : (1) Le standard ne peut-il vraiment pas faire ce que je veux ? (2) Puis-je adapter mon processus au standard ? (3) Cette fonctionnalité justifie-t-elle son coût complet sur 7 ans ? Les projets qui maintiennent le spécifique sous 15% du volume total de fonctionnalités ont un taux de succès de 75%. Au-delà de 30%, ce taux chute à 35%.Les tests progressifsLes tests ne sont pas une phase finale, ils irriguent tout le BUILD. Vous testez dès la première configuration, puis de manière de plus en plus réaliste.3 niveaux de tests :1. Tests unitaires (intégrateur) : Validation technique que chaque fonction marche isolément. Vous surveillez le First Pass Yield (FPY) : pourcentage de tests réussis du premier coup. Un FPY < 70% indique une mauvaise qualité de développement.2. Tests E2E (vos Key Users) : Simulation de scénarios métier complets qui traversent plusieurs modules.Exemple EnergiePlus : Test « De la facture client à l’encaissement » : émission facture → génération écriture comptable → génération prélèvement SEPA → envoi banque → réception fichier retour → rapprochement automatique → lettrage comptable. Ce test valide 6 processus et 4 modules différents.3. UAT (vos utilisateurs finaux) : Recette intensive de 2 à 4 semaines avec des données réelles issues de votre production actuelle. CRITIQUE : Ne testez jamais avec des données fictives. Utilisez une copie anonymisée de votre base actuelle.N’oubliez pas : Un test réussi signifie « tous les bugs détectés sont corrigés et retestés avec succès ». Votre objectif en fin de BUILD : zéro anomalie Bloquante ou Majeure non résolue.La reprise des données : votre responsabilitéLa migration des données est LE point que les clients sous-estiment systématiquement. Et c’est VOTRE responsabilité, pas celle de l’intégrateur.Données statiques (référentiels) : Clients, articles, grilles tarifaires. Elles changent peu et doivent être parfaitement nettoyées avant la bascule.Données dynamiques (transactionnelles) : Factures impayées, soldes comptables, opérations en cours. Elles bougent chaque jour et seront migrées durant le weekend de cutover.Le nettoyage : votre chantier invisibleExemple EnergiePlus : Audit de la base clients avant migration. Situation initiale : 45 000 fiches. Après audit : 8 400 doublons, 5 200 clients inactifs >3 ans, 1 800 fiches incomplètes. Résultat : migration de 29 600 fiches réellement actives et nettoyées. Économie : 5 semaines de rework évitées.Votre Data Quality Score doit dépasser 95% en fin de BUILD. En dessous de 90%, vous allez polluer votre nouveau système dès le premier jour.La répétition générale (Mock Migration)Ne migrez jamais vos données « en vrai » le weekend du go-live sans avoir répété. La Mock Migration vous permet de chronométrer chaque étape et d’optimiser les scripts.Exemple EnergiePlus : Premier test de migration : 16h15 au total. Trop long pour le weekend de bascule (48h). Après optimisation des scripts : 11h20. Validation OK. Attention : L’intégrateur fournit les scripts techniques. Mais c’est VOUS qui nettoyez et validez les fichiers. « Garbage in, garbage out ». Piloter le BUILD par les chiffresPour éviter de piloter à l’aveugle, suivez ces indicateurs chaque semaine.KPI d’avancement :Taux de conception validé (% ateliers Design terminés)Taux de configuration réalisé (% processus paramétrés)Burn-down des développements (jours/homme consommés vs budget)KPI de qualité :First Pass Yield : > 75% (zone d’alerte si < 60%)Couverture de tests : 100% des Must-Have validésStock d’anomalies : réparti par criticité (Bloquant/Majeur/Mineur)KPI de données :Data Quality Score : > 95% en fin de BUILDAlerte rouge : Si le nombre d’anomalies ouvertes augmente plus vite que le nombre de corrections, vous perdez le contrôle. Gel immédiat des nouveaux développements.Les 5 pièges à éviterPiège #1 – L’effet tunnel : Vous ne voyez pas le logiciel pendant 3 mois. Remède : Démos toutes les 2 semaines maximum.Piège #2 – Le « Nice to Have » : Accepter des modifications cosmétiques qui retardent les fonctions critiques. Remède : Utilisez votre Change Control Board, zéro changement non réglementaire.Piège #3 – Tester en labo, déployer en réel : Vous testez avec 5 personnes, vous déployez pour 200. Remède : Tests de charge sur vos volumes et pics réels.Piège #4 – Key Users fantômes : Ils sont censés être à 50-80% sur le projet, en réalité ils sont à 20%. Remède : Si le backfill n’est pas effectif, bloquez le passage en BUILD.Piège #5 – Sous-estimer la reprise de données : Vous pensez que l’intégrateur « va nettoyer ». Remède : Lancez l’audit data dès la semaine 2 du BUILD, pas à la fin.Les chiffres réels du BUILDRépartition de l’effort : 35 à 45% de l’effort total du projetDurée moyenne : Phase Design 4-8 semaines + Construction / Tests 8-16 semaines = 3 à 6 mois au totalDérive tolérable : +10-15% de périmètre est normal. Au-delà de 20%, projet hors contrôle.Taux de spécifique optimal : < 15% pour garantir maintenabilité et succès Et ensuite ? Une fois le BUILD finalisé – Blueprint validé, système configuré, développements testés, données migrées et recette signée – vous entrez dans les phases finales de l’implémentation qui vont concrétiser votre bascule opérationnelle.Prochaines étapes dans IMPLEMENT :Préparation go-live : Planification minutieuse du weekend de cutover, organisation du support de démarrage, formation intensive des utilisateurs finauxGo-live : Bascule effective en production avec accompagnement terrain renforcéStabilisation : Montée en compétence des équipes et résolution des irritants post-démarrage (4 à 8 semaines)Pour maîtriser chaque dimension du BUILD, consultez nos guides détaillés :Conception initiale (Design/Blueprint) : Comment structurer vos ateliers fonctionnels et techniques pour produire un Blueprint exhaustif qui évitera les incompréhensions coûteusesConfiguration & développements : Les techniques de paramétrage avancé et la gouvernance des développements spécifiques pour maintenir votre système maintenableIntégration & interfaces : Comment spécifier et tester vos connexions avec les systèmes tiers pour garantir la fluidité des flux de donnéesData & migration de données : La méthodologie complète de nettoyage, mapping et migration pour réussir votre bascule sans pollution de la baseTests : Les stratégies de test unitaire, E2E et UAT pour détecter et corriger les anomalies avant qu’elles n’impactent votre production Accédez à ces guides pratiques pour approfondir chaque étape du BUILD et sécuriser votre projet (contenus disponibles sur inscription) ArticlesDesign Configuration & développements Intégration & interfaces Data & migration de données Tests
