Déployer un ERP en 90 jours en Afrique centrale : ce qui se joue avant le premier jour
Quatre-vingt-dix jours, ce n’est pas une promesse de vitesse. C’est une contrainte de cadrage.
Un projet ERP qui dérape rarement déraille pendant le déploiement. Il déraille parce que personne n’a écrit, avant de commencer, ce que le projet devait changer dans l’entreprise — et pour qui. Les mois supplémentaires ne servent alors qu’à découvrir en production ce qu’on aurait dû établir en réunion.
Voici comment tenir 90 jours, et ce qu’il faut avoir réglé avant que le compteur démarre.
1. Le travail décisif est antérieur au projet
Avant tout chiffrage, trois questions doivent être traitées séparément. La plupart des avant-ventes les mélangent — et c’est de ce mélange que naissent les projets qui dérivent.
Le quoi — la découverte de projet. Quel est le périmètre réel ? Quels processus, quelles entités, quelles interfaces ? La question paraît évidente ; elle est celle qu’on saute le plus souvent, parce que tout le monde croit connaître la réponse.
Le pourquoi — la synthèse d’impact. Qu’est-ce que ce projet change pour la direction générale ? Pas en fonctionnalités : en délai de clôture, en visibilité sur la trésorerie, en temps passé à produire une déclaration. Un projet dont le « pourquoi » n’est pas écrit noir sur blanc perd son arbitrage au premier conflit de priorité.
Le comment — la revue des processus métier. Comment travaillent réellement les équipes aujourd’hui, par opposition à ce que dit la procédure ? C’est là qu’on découvre les contournements, les fichiers parallèles, les validations informelles — tout ce qui fera échouer une migration si on l’ignore.
Un principe en découle : la démonstration ne vient qu’après. Une démo faite avant d’avoir établi le quoi, le pourquoi et le comment ne vend pas un projet — elle vend un logiciel, et c’est ainsi qu’on se retrouve à déployer des modules dont personne n’avait besoin.
2. L’atelier de découverte, et pourquoi il se tient au tableau
Ces trois questions se traitent dans un atelier structuré en six temps, mené avec le client plutôt que devant lui :
- Moteurs de l’activité et objectifs du projet — ce qui pousse à agir maintenant
- Difficultés actuelles — les points de friction concrets, nommés par ceux qui les vivent
- Capacités nouvelles — ce que l’entreprise saura faire après, qu’elle ne sait pas faire aujourd’hui
- Risques du projet — énoncés à voix haute, pas dissimulés jusqu’au comité de pilotage
- Impacts métier — la traduction des capacités en effets mesurables
- Calendrier — d’aujourd’hui à la mise en service
Le point remarquable est le support : un tableau, pas un diaporama. Son effet le plus utile est social : dessiner ensemble casse le rapport fournisseur-client. Un participant qui prend le feutre cesse de subir une présentation et commence à décrire sa propre entreprise. Il en dit alors nettement plus qu’il n’avait prévu.
C’est précisément le matériau qui manque aux projets qui dérivent.
3. Les 90 jours, phase par phase
Une fois le cadrage établi, le déploiement se déroule en quatre phases bornées.
Audit du système d’information, périmètre arrêté, feuille de route validée avec le client, budget et planning contractuels.
Paramétrage Microsoft, localisation OHADA et COBAC, migration des données, formation des administrateurs.
Déploiement progressif, formation des utilisateurs finaux, tests de recette, ajustements en temps réel.
Bascule en production, documentation, supervision, support N1/N2, plan d’évolution.
Deux observations sur ce découpage.
La phase Structurer est la plus longue, et c’est délibéré. C’est elle qui porte la localisation réglementaire : plan de comptes SYSCOHADA, retenues à la source constatées au règlement, retenue de TVA du collecteur agréé, arrondi du franc CFA à l’unité. Un intégrateur qui la compresse reporte le problème sur la recette, où il coûte plus cher à corriger.
La bascule n’est pas la fin. La phase Pérenniser commence au jour 80 et se poursuit après : c’est elle qui distingue un ERP mis en service d’un ERP réellement adopté.
4. Pourquoi 90 jours, et pas six mois
La question revient à chaque cadrage : pourquoi s’imposer une échéance courte sur un projet structurant ?
Parce qu’un calendrier long ne produit pas un meilleur projet — il produit un projet plus large. Sans date de bascule proche, chaque demande nouvelle trouve sa place : on ajoute un module, on attend une réorganisation, on reporte une décision au prochain comité. Six mois plus tard, le périmètre a doublé et la mise en service n’a pas eu lieu. Ce n’est pas un défaut d’exécution, c’est une propriété des projets sans contrainte : ils absorbent le temps qu’on leur donne.
Quatre-vingt-dix jours agissent comme un filtre. Toute demande doit répondre à une question simple — est-elle indispensable à la mise en service, ou peut-elle attendre la version suivante ? La plupart peuvent attendre. Les traiter dans une phase ultérieure ne les abandonne pas : cela les hiérarchise.
Cette contrainte a un second effet, moins visible. Elle protège l’adhésion des équipes. Un projet annoncé sur six mois perd ses relais internes en chemin : les personnes changent de poste, les priorités se déplacent, l’énergie du lancement se dissipe. Un projet qui livre en trois mois conserve les mêmes interlocuteurs du début à la fin — et un utilisateur qui voit le résultat de ses réunions de cadrage reste engagé. C’est un facteur d’adoption bien plus déterminant que l’ergonomie du logiciel.
Trois conditions rendent l’échéance tenable, et aucune n’est technique : un périmètre écrit et défendu, des interlocuteurs client identifiés et disponibles, et une décision rapide sur les arbitrages. Quand l’une manque, ce n’est pas le délai qu’il faut allonger — c’est la condition qu’il faut rétablir.
5. Ce qui fait dépasser les 90 jours
Trois causes, dans l’ordre de fréquence.
Les données. La reprise est systématiquement sous-estimée. Un fichier client qui contient trois orthographes du même tiers, des soldes qui ne se rapprochent pas, un historique incomplet : rien de tout cela ne se découvre au jour 60 sans faire glisser le calendrier. Le seul remède est de regarder les données pendant la phase Planifier, pas après.
La disponibilité des équipes du client. Un déploiement en 90 jours suppose des interlocuteurs disponibles. Quand le contrôleur de gestion est mobilisé sur la clôture, la recette attend. Cette contrainte se planifie ; elle ne se déplore pas.
Le périmètre qui s’étend. Chaque ajout accepté en cours de route est un jalon repoussé. C’est là que le « pourquoi » écrit au départ devient un outil de décision : une demande qui ne sert pas l’objectif initial se traite dans une phase ultérieure, pas dans celle-ci.
6. Cinq questions avant de signer un projet à 90 jours
- Le « pourquoi » du projet est-il écrit, et validé par la direction générale ? Pas la liste des fonctionnalités : l’effet attendu sur l’entreprise.
- Quelqu’un a-t-il regardé les données réelles ? Pas leur description — les données.
- Les phases sont-elles bornées en jours dans le contrat, avec ce qui se termine à chacune ?
- Qui, côté client, est disponible et sur quelle période ? Nommément.
- La localisation réglementaire est-elle une phase du projet ou une option ? En zone CEMAC, une localisation traitée en option est une localisation qui n’arrivera pas.
Un projet dont ces cinq réponses sont écrites tient ses 90 jours. Les autres découvrent leur périmètre en chemin.
SIGA IT Consulting déploie Dynamics 365 Business Central en Afrique centrale. Découvrez notre offre Applications d’entreprise ou notre méthode en quatre phases — ou commencez par mesurer où en est votre entreprise avec notre diagnostic de maturité.
