En bref : pour ceux qui sont pressés
La recette est la phase la plus négligée des projets ERP et CRM et pourtant celle qui détermine si le démarrage sera serein ou chaotique. Tester avant de déployer, ce n'est pas une formalité : c'est la dernière ligne de défense avant que vos équipes et vos données réelles ne soient exposées à un système imparfait.
Déployer sans tester : la recette du désastre
Il existe une tentation forte en fin de projet : celle d'aller vite. Le planning a glissé, les équipes sont fatiguées, le prestataire pousse pour clôturer. Et là, quelqu'un propose de "raccourcir les tests" pour tenir la date de démarrage.
C'est presque toujours une erreur.
Les anomalies découvertes avant la mise en production coûtent dix fois moins cher à corriger qu'après. Avant, c'est une correction dans un environnement de test, sans impact sur les opérations. Après, c'est une correction en urgence sur un système en production, avec des utilisateurs bloqués, des données potentiellement corrompues, et une direction qui demande des comptes.
La phase de recette n'est pas une formalité administrative. C'est un investissement de quelques semaines qui protège des mois de perturbations.
Les différentes phases de test dans un projet ERP/CRM
Un plan de recette sérieux ne se résume pas à "cliquer partout pour voir si ça plante". Il est structuré en phases progressives, chacune avec un objectif précis.
Tests unitaires : valider module par module
On teste chaque fonctionnalité isolément, dans des conditions contrôlées. Est-ce que la création d'un bon de commande fonctionne correctement ? Est-ce que le calcul de TVA est juste selon les différents cas (taux réduit, exonération, autoliquidation) ? Est-ce que la génération d'une facture produit le bon document ?
Ces tests sont généralement réalisés par le prestataire AMOE en premier, puis vérifiés par le référent interne. Ils permettent de détecter les erreurs de paramétrage basiques avant d'exposer les utilisateurs.
Tests d'intégration : valider les flux entre modules
C'est là que les vraies surprises apparaissent. Un module peut fonctionner parfaitement seul et poser problème dès qu'il interagit avec un autre.
Exemple concret : la commande client est bien enregistrée, la livraison est bien générée, mais la facture ne reprend pas les bons prix parce que les règles tarifaires ne sont pas correctement transmises d'un module à l'autre. Chaque module est correct — c'est le flux qui est cassé.
Les tests d'intégration suivent des scénarios bout en bout : de la création du devis jusqu'à l'encaissement, de la commande fournisseur jusqu'au paiement. Ils doivent couvrir les cas normaux et les exceptions.
Tests utilisateurs (UAT : User Acceptance Testing)
C'est la phase de validation par les équipes métier. Des utilisateurs représentatifs, pas forcément les plus experts, mais les plus représentatifs de l'usage réel, testent l'outil sur leurs propres cas de travail.
L'objectif n'est pas de trouver des bugs techniques (les phases précédentes s'en chargent) mais de valider que l'outil correspond aux besoins exprimés et que les utilisateurs peuvent accomplir leurs tâches sans blocage majeur.
C'est aussi la meilleure phase pour détecter les besoins non exprimés pendant le cadrage, ceux qui n'apparaissent que quand on touche vraiment à l'outil (voir notre article sur le rôle du chef de projet AMOA).
Tests de charge et de performance
Souvent oubliés en PME, ces tests vérifient que le système tient la route dans des conditions d'utilisation réelles : plusieurs utilisateurs connectés simultanément, imports de fichiers volumineux, génération de rapports lourds. Un outil qui fonctionne parfaitement avec un utilisateur peut ralentir considérablement à dix utilisateurs simultanés.
Tests de sécurité et de droits d'accès
Vérifiez que chaque profil utilisateur accède uniquement à ce qu'il doit voir. Un commercial ne doit pas voir les marges. Un gestionnaire de stock ne doit pas pouvoir modifier le plan de comptes. Ces vérifications semblent évidentes — elles sont pourtant régulièrement oubliées.
Qui doit tester ? Composer une équipe pilote efficace
La recette ne peut pas être assurée uniquement par le prestataire. Ce serait comme demander à un cuisinier de goûter lui-même son plat et de décider s'il est bon pour le client.
Une équipe pilote efficace comprend :
Un référent par service concerné, pas forcément le manager, mais la personne qui connaît le mieux les cas complexes et les exceptions
Le DSI ou RSI pour les aspects techniques et de sécurité (voir notre article sur le rôle du DSI/RSI)
Le DAF ou un représentant financier pour valider les flux comptables, les calculs de TVA, et les rapports financiers
Le chef de projet AMOA pour coordonner, prioriser les anomalies, et arbitrer ce qui est bloquant ou non
Ce que cette équipe n'est pas : un groupe de volontaires disponibles deux heures entre deux réunions. La recette demande du temps dédié. Si les testeurs ne sont pas libérés de leurs tâches habituelles pendant cette phase, les tests seront bâclés — et les problèmes ressortiront en production.
Construire un plan de recette : les éléments essentiels
Un plan de recette n'a pas besoin d'être un document complexe. Il doit contenir :
Les scénarios de test : chaque cas à tester est décrit avec les données d'entrée, les étapes à suivre, et le résultat attendu. Pas de test sans résultat attendu défini à l'avance — sinon on ne sait pas si le test est passé ou non.
Une grille de suivi : pour chaque scénario, statut (à tester / en cours / passé / en anomalie), date de test, testeur, et observations. Un simple tableur suffit pour un projet PME.
Une classification des anomalies :
Bloquante : empêche l'utilisation du système ou produit des données erronées : doit être corrigée avant le démarrage
Majeure : gêne significative mais contournement possible : à corriger rapidement après démarrage
Mineure : inconfort ou amélioration souhaitable : planifiable dans une version ultérieure
Un processus de remontée clair : comment signale-t-on une anomalie ? À qui ? Sous quel délai le prestataire s'engage-t-il à répondre ? (voir notre article sur l'AMOE externe)
Les critères GO / NO-GO avant la mise en production
C'est la décision la plus importante du projet. Elle doit être prise de façon objective, pas sous la pression du planning.
Critères GO :
Zéro anomalie bloquante ouverte
Toutes les anomalies majeures ont une solution identifiée (correction ou contournement documenté)
Les données migrées ont été validées par les référents métier et le DAF
Les utilisateurs clés ont été formés et ont validé leur formation
Les accès de production sont configurés et testés
Les procédures de sauvegarde et de retour arrière sont en place
Critères NO-GO :
Des anomalies bloquantes non résolues subsistent
Les données migrées présentent des incohérences non expliquées
Des utilisateurs clés n'ont pas été formés
L'infrastructure de production n'a pas été testée en charge
Si l'un des critères NO-GO est présent, la date de démarrage doit être repoussée. C'est une décision difficile — elle est presque toujours la bonne.
La recette de données : le point le plus sous-estimé
Migrer des données, c'est plus que les transférer. C'est valider que ce qui est arrivé dans le nouveau système est fidèle, complet, et cohérent avec l'existant.
Quelques vérifications indispensables :
Comparer les totaux comptables entre l'ancien et le nouveau système (soldes clients, fournisseurs, stocks)
Vérifier un échantillon représentatif de fiches (clients, fournisseurs, articles) au niveau du détail
Tester les calculs qui dépendent des données historiques (tarifs, encours, délais de paiement)
S'assurer que les données sensibles (mots de passe, données personnelles) ont été traitées conformément au RGPD
Un écart de données non détecté avant le démarrage peut prendre des semaines à corriger en production, avec un impact direct sur les opérations et la confiance des utilisateurs.
FAQ : questions fréquentes
Combien de temps faut-il prévoir pour la phase de recette ?
Pour une PME de 20 à 80 personnes avec un déploiement multi-modules, comptez entre deux et six semaines. Moins que ça, soit le projet est très simple, soit les tests sont insuffisants. Cette durée doit être intégrée dans le planning initial, pas ajoutée en urgence en fin de projet.
Le prestataire peut-il réaliser la recette à notre place ?
Il peut réaliser les tests unitaires et d'intégration. En revanche, la validation utilisateur (UAT) doit être faite par vos équipes. C'est non négociable : seuls vos utilisateurs savent si l'outil correspond à leur réalité de travail. Un prestataire qui propose de faire la recette entièrement à votre place doit alerter.
Que faire si des anomalies bloquantes sont découvertes tardivement ?
Repoussez le démarrage. C'est la seule décision raisonnable. Communiquez clairement sur les raisons auprès des équipes : une explication honnête est toujours mieux reçue qu'un démarrage chaotique suivi de semaines de dysfonctionnements.
Faut-il tester l'outil en conditions réelles avec de vraies données ?
Pour les tests utilisateurs, oui, dans la mesure du possible. Utiliser des données anonymisées ou représentatives de la réalité permet de détecter des cas que des données fictives ne révèlent pas. Attention cependant à ne pas utiliser des données personnelles réelles dans un environnement de test non sécurisé.
Comment gérer la coexistence de l'ancien et du nouveau système pendant la transition ?
Définissez une date de bascule claire et tenez-vous y. La double saisie prolongée est épuisante et source d'erreurs. Prévoyez une période de "lecture seule" sur l'ancien système après la bascule (pour consulter l'historique) mais n'autorisez plus de saisie dessus. Plus vite les équipes n'ont plus le choix, plus vite elles adoptent le nouveau système.
Vous avez maintenant une vision complète du cycle d'un projet ERP ou CRM réussi : du rôle de l'AMOE à la recette finale, en passant par le pilotage AMOA, l'alignement DSI/métier, et le pilotage financier. Chaque maillon compte et chaque article de cette série vous donne les clés pour le maîtriser.