Pourquoi il faut corriger le processus avant le déploiement d'un système, pas en même temps
Nous avons déployé un CRM à trois reprises : dans une agence, dans une production saisonnière de cadeaux d'entreprise et sur une plateforme de prise de rendez-vous en ligne. Trois entreprises, trois secteurs, trois équipes. Un seul point commun : partout, la première version du paramétrage a été l'organisation existante, transposée telle quelle dans des champs et des statuts.
C'est précisément là que se joue le sort du projet. Si le processus, avant le déploiement, comportait des champs facultatifs, des exceptions gérées à la main et des « ici, en général, on appelle et on s'arrange », tout cela migre dans le système et acquiert le statut de norme. Corriger ensuite coûte plus cher : le désordre dispose désormais d'un paramétrage, d'intégrations et d'utilisateurs formés.
Le système ne remet pas de l'ordre dans le processus : il le fige. Tout ce qui n'a pas été tranché avant le déploiement se transforme en paramétrage, en exception et en habitude utilisateur, et le coût de la correction augmente d'un ordre de grandeur. Il faut donc trancher trois points avant le lancement du projet : la liste des données obligatoires, les règles de calcul et les points de transfert entre rôles.
Ce que le système fige exactement
Dire que « le système fige le désordre » ressemble à une métaphore, jusqu'à ce qu'on la décompose en mécanismes concrets. Il y en a quatre, et chacun s'observe dès les premières semaines suivant la mise en service.
Un champ facultatif reste éternellement vide. Au moment du paramétrage, l'argument « rendons-le facultatif, sinon personne ne le remplira » l'emporte presque toujours. Un trimestre plus tard, on découvre que le champ n'est renseigné que sur 20 % des enregistrements et qu'aucun rapport ne peut s'appuyer dessus. Décider quelles données sont obligatoires relève du processus, pas de la technique, et il est trop tard pour trancher après le lancement : il faudra désormais ressaisir les données rétroactivement.
Une exception se transforme en statut. « Pour ce client, on fait autrement » paraît anodin au moment du déploiement, et on crée pour cela un statut ou un type d'opportunité à part. Un an plus tard, il y a douze statuts de ce genre, et aucun collaborateur ne sait expliquer la différence entre quatre d'entre eux. Chaque statut est une ramification dans les rapports, dans les droits d'accès et dans la formation des nouveaux arrivants.
Un arrangement oral devient invisible. Là où deux collègues réglaient auparavant une question de vive voix, le système affiche un vide : la demande reste bloquée sur un statut, alors que le travail avance. Formellement, le processus s'exécute ; en réalité, il contourne le système, et les données cessent de refléter la réalité. Le responsable prend ensuite ses décisions sur un rapport qui décrit autre chose que ce qui se passe.
Un calcul fait de mémoire migre vers un champ libre. Si les règles de calcul n'ont pas été formalisées avant le déploiement, le système se retrouve avec un champ « montant » dans lequel le commercial saisit un chiffre. Le système a l'air déployé, mais l'arithmétique reste manuelle, avec toutes les erreurs qu'elle produisait déjà avant.
| Ce qui n'a pas été tranché avant le déploiement | En quoi cela se transforme | Quand cela se découvre |
|---|---|---|
| Quelles données sont obligatoires | Un champ vide sur la majorité des enregistrements | Dès la première tentative de construire un rapport |
| Ce qui constitue une exception | Une dizaine de statuts sans différence réelle | Lors de la formation d'un nouveau collaborateur |
| Où se situe le transfert entre rôles | Le travail contourne le système | Quand le rapport diverge des faits |
| Selon quelle règle le montant est calculé | Un champ libre pour la saisie manuelle | Lors du rapprochement avec la comptabilité |
| Qui est propriétaire du processus | Les paramètres changent au gré de qui insiste le plus | D'un coup, deux ou trois trimestres plus tard |
Le point commun aux cinq lignes est le moment de la découverte. Aucun problème ne se manifeste pendant le projet ; tous émergent après sa clôture formelle, quand l'équipe de déploiement a déjà été dissoute et le budget consommé.
Un phénomène à quelle échelle
Les déploiements de systèmes d'entreprise sont mesurés régulièrement, et le constat est stable : le problème ne tient ni à la technologie ni à l'éditeur.
Plus d'un quart des organisations ayant déployé un ERP déclarent avoir dépassé le budget du projet, et près d'un quart avoir dépassé les délais prévus.
La réserve s'impose et je la formule moi-même : il s'agit du rapport d'un cabinet de conseil qui vend justement l'accompagnement de déploiements ERP. L'échantillon n'est pas aléatoire — les répondants ont réagi à une invitation, un biais en faveur des clients et abonnés du cabinet est probable. Le chiffre vaut comme ordre de grandeur, pas comme mesure du marché.
En moyenne, seules 48 % des initiatives de digitalisation à l'échelle de l'organisation atteignent ou dépassent les résultats métier prévus. Pour le groupe d'entreprises que les analystes distinguent comme leaders de la transformation numérique, ce même indicateur atteint 71 %.
Il s'agit d'un communiqué de presse, pas du rapport complet : l'instrument d'enquête, la période de collecte et le libellé exact des questions ne sont pas publiés. Ce qui compte ici n'est pas le pourcentage lui-même, mais l'écart de 23 points entre les leaders et les autres : il montre que le résultat dépend non de la présence d'un système, mais de la manière dont le travail s'organise autour de lui.
Ce que nous avons appris à faire avant le lancement
Après le troisième déploiement, l'ensemble des décisions préalables s'est stabilisé. Il est court et ne demande ni analyste ni budget — seulement du temps de la part du propriétaire du processus.
La première décision est la plus désagréable, car elle porte sur des interdictions. Un champ obligatoire signifie que quelqu'un ne pourra plus terminer son travail de la manière habituelle, ce qui suscitera de la résistance. Mais ce sont précisément les champs obligatoires qui produisent les rapports pour lesquels le système a été acheté — ce même mécanisme était à l'origine de l'effet obtenu avec notre générateur de propositions commerciales.
La deuxième décision supprime la saisie libre du système partout où un calcul est possible. Tant que le montant est saisi à la main, il n'y a pas d'automatisation : il y a un formulaire électronique pour du travail manuel.
La troisième décision concerne les transferts entre rôles. Chaque transfert doit devenir un événement dans le système, pas un accord verbal. Si le travail passe d'une personne à l'autre à l'oral, le système affichera une chose pendant qu'une autre se produit.
Précisons ce qui ne figure pas dans cette liste. On n'y trouve pas de description du processus « tel qu'il est » sous forme de schéma de vingt pages. Une telle description est presque toujours produite, presque jamais lue, et n'aide à trancher aucune des trois décisions ci-dessus : elle consigne un comportement observé, alors que les décisions portent sur la norme. Lors de notre troisième déploiement, nous avons renoncé à la description complète et consacré le temps ainsi libéré à deux journées d'examen des champs obligatoires — la seule étape de préparation qui ait réellement influé sur le résultat.
Le second élément absent de la liste est le choix de la plateforme. Ce choix n'est pas dénué de sens, mais il est secondaire : les trois décisions se formulent de façon identique pour n'importe lequel des systèmes courants, et aucune ne dépend de l'éditeur. L'ordre dans lequel on choisit d'abord le système, puis on discute du processus, garantit que la conversation sur la norme se tiendra dans les termes des contraintes d'un produit donné, et non dans les termes du métier.
Pourquoi corriger après le lancement coûte plus cher
L'écart de coût n'est pas une impression, c'est une arithmétique de dépendances. Avant le lancement, une décision se modifie dans un document. Après le lancement, la même décision touche le paramétrage, les données accumulées, les intégrations, les rapports et les habitudes des utilisateurs, et chacune de ces couches exige un travail à part.
Sur un échantillon de 1 471 projets IT, le dépassement budgétaire moyen s'élève à 27 %, mais un projet sur six s'est révélé être un « cygne noir » avec un dépassement moyen de 200 %. Le risque se concentre dans la queue de la distribution, pas dans la moyenne.
J'approfondis ce même sujet dans l'article consacré à l'erreur d'estimation de la charge de travail. Un aspect compte particulièrement ici : le dépassement n'est pas réparti uniformément. Les projets dont le périmètre était défini par les capacités du système, et non par des décisions sur le processus, se retrouvent précisément dans cette queue de distribution — parce que chaque décision reportée réapparaît sous forme de travail non planifié.
Quatre questions à trancher avant de lancer un projet de déploiement
Sans quelles données un enregistrement n'a-t-il pas de sens
Une liste de trois à cinq champs. Si elle est plus longue, vous décrivez ce qui est souhaitable, pas ce qui est obligatoire.
Que calcule le système ici
Chaque montant, chaque délai et chaque statut qui peuvent être déduits d'autres données doivent être calculés, pas saisis.
Où le travail change-t-il de propriétaire
Recensez les points de transfert. Chacun doit devenir un événement : qui a transmis, qui a reçu, à quel moment.
Qui peut modifier les paramètres
Une seule personne, avec le droit de dire non. Sans elle, un an plus tard, le paramétrage reflétera l'historique des demandes, pas la logique du processus.
Si aucune de ces quatre questions n'a de réponse, le projet de déploiement n'a pas encore commencé : c'est un achat qui est en cours.
Questions fréquemment posées
Faut-il documenter le processus avant de déployer un CRM ou un ERP ?
Le documenter intégralement n'est pas indispensable, mais trois décisions doivent être prises : quelles données sont obligatoires, ce que le système calcule à la place de l'humain, et où se situent les transferts entre rôles. Ces trois décisions occupent quelques séances de travail du propriétaire du processus et pèsent plus lourd que le choix de la plateforme. Une cartographie de l'existant complète sans elles ne sauve rien, et avec elles, elle n'est généralement pas nécessaire.
Peut-on corriger le processus en parallèle du déploiement ?
C'est possible, mais il faudra payer deux fois : d'abord pour le paramétrage adapté à l'ancien ordre, puis pour le reparamétrage adapté au nouveau, avec la migration des données accumulées. L'option parallèle se justifie quand le processus ne peut être compris qu'avec un système opérationnel — mais il est alors plus honnête d'appeler la première étape un pilote avec refonte prévue d'avance, plutôt qu'un déploiement.
Que faire si le système est déjà déployé et que le désordre persiste ?
Ne reparamétrez pas tout d'un coup. Prenez un seul rapport réellement utilisé par un responsable, et remontez-le de bas en haut : quels champs y entrent, sur combien d'enregistrements sont-ils renseignés, d'où viennent les valeurs. On découvre en général qu'il suffit de rendre obligatoires deux ou trois champs et de supprimer un champ libre pour que le rapport commence à refléter la réalité.
Qui doit prendre ces décisions — l'IT ou le métier ?
Le propriétaire du processus, c'est-à-dire celui qui répond du résultat, pas du système. Signe d'une bonne répartition : l'IT répond à la question « comment le faire », le propriétaire du processus répond à la question « que considère-t-on comme la norme ». Si c'est le prestataire qui décide des champs obligatoires, alors la question de la norme n'a été posée à personne.
L'affirmation « trois déploiements sur trois ont commencé par la reprise du processus existant tel quel » concerne les déploiements de CRM dans trois entreprises de l'auteur : une agence digitale (Megaplan comme système d'enregistrement), une production saisonnière de cadeaux d'entreprise et une plateforme de prise de rendez-vous en ligne. La liste des décisions préalables et le phasage du processus sont issus du référentiel de relation client de la même période. Il s'agit de documents internes à l'entreprise de l'auteur ; ils n'ont pas été vérifiés par un tiers indépendant et sont présentés à titre d'illustration du mécanisme. La liste des cinq décisions différées et le moment de leur découverte ont été reconstitués à partir de l'expérience de ces déploiements.
- Panorama Consulting Group. The 2026 ERP Report (enquête auprès de 170 organisations, janvier 2025 – janvier 2026). panorama-consulting.com
- Gartner. Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets. Communiqué de presse, 22 octobre 2024. gartner.com
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, septembre 2011. hbr.org