Pourquoi fait-on toujours de la conception en recette ?

Pourquoi les difficultés apparaissent toujours au même moment dans un projet de transformation

Sur la plupart des programmes de transformation, il existe un moment où l’ambiance change. Les ateliers se sont enchaînés, le calendrier paraissait tenable, les indicateurs étaient rassurants. Puis arrivent les tests utilisateurs. Le nombre d’anomalies explose, des cas de gestion jamais évoqués font leur apparition, les arbitrages deviennent urgents et les tensions montent entre les équipes opérationnelles, la DSI et les partenaires du déploiement.

La phrase que j’ai le plus entendue en dix ans d’accompagnement de directions financières est : “On est en train de faire de la conception en recette.”

Pendant longtemps, j’ai vu cela comme le symptôme d’un cadrage insuffisant. Avec le recul, je pense que c’est un révélateur plus profond : la recette ne teste pas seulement la qualité du projet. Elle teste la maturité de l’entreprise qui porte le changement : responsabilités floues, règles de gestion jamais harmonisées, données peu fiables, dépendance excessive à quelques personnes clés.

Je vous partage quelques enseignements que j’en ai retirés.

1. Donnez à vos référents métiers les moyens de réussir

C’est le sujet que j’aborde en premier, parce que c’est l’un des plus critiques sur tout projet de transformation. Ces profils participent aux ateliers, préparent les arbitrages, valident les scénarios, accompagnent leurs collègues et contribuent à la conduite du changement tout en continuant à assurer leurs responsabilités quotidiennes.

En dix ans, je n’ai jamais vu une implémentation se dérouler sereinement lorsque ces personnes devaient gérer l’ensemble de ces sujets entre deux réunions et quelques urgences opérationnelles.

Le temps investi sur ces profils se retrouve dans la qualité des choix réalisés, dans l’adoption de la solution et dans la stabilité du fonctionnement futur. C’est un investissement, pas une charge.

2. Définissez votre cible avant de choisir comment la mettre en œuvre

La réflexion sur le fonctionnement futur doit précéder la réflexion sur la solution. Ce conseil paraît évident, mais il est rarement appliqué. Dans la réalité, la cible globale est pensée dans ses grandes lignes mais rarement par processus de bout en bout. Résultat : une cohérence d’ensemble difficile à tenir et des angles morts aux frontières entre domaines, précisément là où les difficultés apparaissent le plus souvent.

Prenons l’exemple d’un écart d’inventaire. Au départ, le sujet semble purement logistique. Puis arrivent les questions comptables sur le schéma d’écriture, sur la validation des écarts significatifs, sur les provisions éventuelles. Le contrôle de gestion s’interroge sur les impacts analytiques. Tout le monde réalise alors que le sujet n’avait jamais été traité sur l’intégralité de son cycle de vie. Ce qui n’a pas été clarifié lors de la définition de la cible réapparaît plus tard sous forme d’évolution ou de correction, avec des impacts financiers et planning.

Avant de penser outil, faites travailler ensemble toutes les parties prenantes concernées par un flux de bout en bout. Transformez votre schéma directeur en initiative d’entreprise, pas en succession d’ateliers métiers indépendants.

3. Reprenez la main sur la phase de conception

Une situation que je rencontre très fréquemment est celle d’ateliers de conception qui se transforment progressivement en démonstrations. Les utilisateurs découvrent les écrans de leur nouvel outil au fil de l’eau, réagissent ponctuellement, valident ce qui leur paraît cohérent. Quelques mois plus tard, certains s’étonnent que le résultat ne corresponde pas à leurs attentes. Ce n’est pas un sujet de logiciel mais un sujet d’appropriation.

Les démarches les plus fluides sont celles où les métiers présentent eux-mêmes leurs exigences fonctionnelles et leurs règles de gestion. L’intégrateur intervient ensuite pour expliquer comment l’application y répond.

Cette inversion change tout : les utilisateurs passent d’une posture de validation à une posture de construction. Lorsqu’ils ont contribué à bâtir la solution, l’adoption est beaucoup plus naturelle et les remises en question tardives beaucoup plus rares.

« La recette ne teste pas seulement la qualité du projet. Elle teste la maturité de l’entreprise qui porte le changement. »

4. Traitez la recette comme un projet à part entière

Un scénario de test ne consiste pas à vérifier qu’un écran répond correctement. Il doit confirmer la cohérence d’un flux complet : référentiels, opérations, contrôles, impacts financiers, restitutions. Un gestionnaire saisit une commande, un approvisionneur réceptionne, un comptable vérifie les mouvements générés, un contrôleur de gestion analyse les imputations. Lorsqu’un blocage apparaît au milieu de cette chaîne, c’est l’ensemble du dispositif qui est impacté.

J’ai vu de nombreuses recettes s’enliser parce que leur orchestration avait été sous-estimée. Quelques facteurs qui font la différence :

• Construisez votre cahier de tests de bout en bout : du référentiel au reporting, interfaces comprises, avec toutes les équipes concernées, des dates et des durées estimées de réalisation par scénario. En cas de blocage, la replanification n’en sera que plus simple.
• Réunissez physiquement les recetteurs : la proximité accélère la résolution des blocages et rend les tests transverses beaucoup plus fluides.
• Soignez vos données de test : des jeux représentatifs, idéalement issus d’une reprise partielle des données réelles, permettent de tester des situations proches de la réalité du terrain.
• Anticipez l’automatisation des scénarios de non-régression : sans cela, les retests mobilisent les équipes métier pendant des semaines entières sur des tâches à faible valeur ajoutée.

5. Ne cantonnez pas la Finance à son seul périmètre

Les SI Finance sont construits autour des flux métiers. La comptabilité n’est plus le point d’entrée du processus, mais son résultat. Elle reste pourtant garante de sujets structurants : conformité réglementaire, fiscalité, qualité de l’information financière, production des reportings.

J’ai vu plusieurs projets où les processus de gestion avaient été correctement définis, mais où les impacts financiers et normatifs n’avaient été que survolés. Ce sont naturellement ces sujets (taxes, intercompagnies, cut-off, exigences légales…) qui surgissent en recette.

Les équipes Finance doivent rester impliquées bien au-delà de leur seul périmètre fonctionnel car leur vision transverse est souvent le dernier filet de sécurité.

Que faire lorsque la recette dérive ?

Lorsque cette étape met en évidence des lacunes importantes, la tentation est souvent de repousser certains sujets après le démarrage afin de préserver le planning annoncé.

Mon expérience m’a appris l’inverse. Lorsque le nombre de sujets structurants insuffisamment traités devient trop important, mieux vaut prendre le temps de reprendre la conception sérieusement plutôt que de déplacer le problème dans le run.

Une application implémentée avec une faible adhésion génère des répercussions qui peuvent s’installer durablement : fichiers Excel parallèles, contournements de processus, retraitements manuels, perte de confiance des utilisateurs et dégradation progressive de la qualité des données. Autrement dit, une dette projet qui devient rapidement une dette opérationnelle.

Quelques mois de retard coûtent moins cher que plusieurs années de fonctionnement dégradé.

C’est précisément pour aider les directions financières à identifier ces risques en amont que j’ai développé un diagnostic de maturité des transformations Finance — pour mettre en lumière les zones de fragilité avant qu’elles ne freinent votre projet.

Si ces sujets vous parlent, je serais ravie d’échanger avec vous.