Votre ERP est paramétré. Les ateliers sont terminés. L’intégrateur vous annonce que “tout est prêt pour les tests”. Et c’est là que commence la phase la plus sous-estimée de tout projet ERP : la recette.
Une recette bâclée, c’est un go-live qui se transforme en gestion de crise. Des factures qui ne sortent pas. Des stocks qui ne correspondent plus. Des key users qui appellent le support toutes les 10 minutes. Et un retour en arrière qui coûte plus cher que le projet lui-même.
Ce guide vous donne une méthodologie complète pour organiser vos tests, structurer votre recette et prendre une décision de go-live basée sur des faits, pas sur de l’optimisme.
Pourquoi la recette ERP est la phase la plus sous-estimée
Ce que coûte un go-live raté
Les exemples ne manquent pas. En 2017, Revlon a perdu 64 millions de dollars de commandes non traitées après un go-live SAP précipité dans son usine de Caroline du Nord (CIO.com). En 1999, Hershey avait compressé son calendrier d’implémentation de 48 à 30 mois, résultat : 100 millions de dollars de commandes bloquées pendant la période d’Halloween (TechTarget).
Dans ces deux cas, le même schéma : des tests insuffisants, une pression sur le planning, et un go-live déclenché avant que le système ne soit validé par les utilisateurs finaux.
À une échelle plus modeste, les conséquences pour une PME sont tout aussi concrètes : reprises manuelles de données, arrêts de production, facturation gelée pendant des jours, et surtout une perte de confiance des équipes envers le nouveau système.
Les 3 types de tests indispensables
Avant de parler de méthodologie, il faut distinguer trois niveaux de tests qui se complètent :
- Tests unitaires : chaque fonction est testée isolément (créer une fiche article, saisir une commande, calculer une TVA). C’est le travail de l’intégrateur, validé par l’IT interne.
- Tests d’intégration : les modules communiquent entre eux. Une commande client déclenche-t-elle un bon de livraison ? La livraison génère-t-elle une facture ? La facture impacte-t-elle la comptabilité ?
- Tests d’acceptation utilisateur (UAT) : les key users exécutent des scénarios métier complets, de bout en bout, dans des conditions proches de la production. C’est le verdict final, celui qui conditionne le go/no-go.
La recette au sens large englobe ces trois niveaux. Mais c’est l’UAT qui fait la différence entre un go-live maîtrisé et un go-live subi.
Préparer la recette, avant d’exécuter un seul test
Constituer l’équipe de recette
La recette n’est pas un projet IT. C’est un projet métier piloté par l’IT. L’équipe doit inclure :
- Les key users : 1 par processus métier majeur (achats, ventes, production, compta, RH). Ce sont eux qui valident que le système correspond à leur réalité quotidienne.
- Le chef de projet ERP : il coordonne le planning de recette, priorise les anomalies et arbitre les cas limites.
- Un référent IT : il gère l’environnement de test, les accès, les jeux de données et le lien avec l’intégrateur.
- L’intégrateur : il corrige les anomalies remontées et documente les écarts entre le paramétrage et le besoin.
Comptez 20 à 30 % du temps des key users pendant la recette. Ce n’est pas du temps “en plus”, c’est du temps investi pour éviter trois mois de galère après le go-live.
Définir les scénarios de test métier
Un scénario de test n’est pas “tester le module achats”. C’est un enchaînement d’étapes précis, mesurable, avec un résultat attendu documenté.
Exemples de scénarios end-to-end :
- Order-to-cash : devis → commande → livraison → facture → encaissement → écriture comptable
- Procure-to-pay : demande d’achat → commande fournisseur → réception → facture fournisseur → paiement → rapprochement bancaire
- Record-to-report : saisie d’écritures → clôture mensuelle → liasse fiscale → reporting
- Hire-to-retire (si module RH) : embauche → fiche salarié → paie → DSN → solde de tout compte
Pour chaque scénario, documentez : les étapes, les données d’entrée, le résultat attendu, les modules traversés, et les interfaces externes concernées (banque, EDI, e-commerce).
Construire des jeux de données réalistes
C’est le piège classique : tester avec 10 articles propres, 5 clients sans historique, et zéro cas particulier. Le jour du go-live, le système croise 15 000 références, des clients avec des conditions tarifaires spéciales, des remises cascadées et des devises multiples.
Un jeu de données réaliste doit inclure :
- Un échantillon représentatif du fichier article (y compris les cas tordus : articles composés, gestion de lots, articles obsolètes)
- Des clients avec des conditions de paiement variées (comptant, 30 jours fin de mois, escompte)
- Des commandes historiques pour tester la reprise de données
- Des cas d’exception : avoirs, retours, commandes partielles, livraisons multi-sites
Si vos jeux de données sont trop propres, vos tests le seront aussi, et vos problèmes apparaîtront en production.
Exécuter les tests UAT, méthodologie en 5 étapes
Étape 1, Tests unitaires par module
L’intégrateur commence par vérifier chaque fonction individuellement. Créer un article, modifier une fiche client, lancer un calcul de besoin, générer une écriture comptable. C’est la base : si les briques élémentaires ne fonctionnent pas, inutile de tester l’assemblage.
Résultat attendu : chaque fonction produit le résultat documenté dans les spécifications. Les tests unitaires sont tracés (tableur ou outil dédié) avec le statut OK/KO et la date d’exécution.
Étape 2, Tests d’intégration inter-modules
On vérifie que les modules communiquent correctement. Une commande de vente dans le module commercial doit générer un ordre de préparation dans le WMS, une écriture de chiffre d’affaires en comptabilité, et une mise à jour du stock.
Les points de friction classiques :
- Écarts d’arrondi entre modules (TVA, remises)
- Données manquantes dans les flux (un champ obligatoire en compta qui n’est pas renseigné côté vente)
- Séquences de numérotation incohérentes (factures, bons de livraison)
- Droits d’accès qui bloquent un flux inter-module
Étape 3, Tests de bout en bout (end-to-end)
Les key users exécutent les scénarios métier complets définis en phase de préparation. C’est le cœur de l’UAT. Chaque key user joue son rôle réel : le commercial saisit un devis, le magasinier prépare la commande, le comptable rapproche la facture.
Les outils de test des éditeurs facilitent cette phase. SAP Solution Manager offre un module Test Suite complet pour planifier, exécuter et tracer les tests avec analyse d’impact (SAP Support). Odoo propose un mode test natif avec bases de données sandbox séparées. NetSuite fournit des environnements sandbox avec rafraîchissement automatique des données de production.
Chaque test end-to-end doit être documenté : étapes exécutées, résultat obtenu vs. résultat attendu, captures d’écran si écart, et classification de l’anomalie éventuelle.
Étape 4, Tests de charge et performance
Un ERP qui fonctionne avec 3 utilisateurs simultanés peut s’effondrer avec 50. Les tests de charge vérifient :
- Le temps de réponse sur les transactions critiques (saisie de commande, consultation de stock, génération de facture) avec le nombre d’utilisateurs simultanés prévu
- Le comportement du système en pic d’activité (clôture mensuelle, campagne de facturation)
- La tenue de la base de données avec un volume de données réaliste (pas 100 lignes, 100 000 lignes)
Pour les ERP cloud (NetSuite, Odoo SaaS, Cegid XRP Flex), les tests de charge sont souvent limités par le contrat SaaS, vérifiez les engagements de performance de l’éditeur.
Pour les ERP on-premise ou hybrides, un test de charge avec un outil comme JMeter ou Gatling sur les processus critiques est fortement recommandé.
Étape 5, Tests de reprise de données
La reprise de données est souvent le parent pauvre des projets ERP. Pourtant, c’est elle qui détermine si le go-live se passe avec des données fiables ou avec un système neuf rempli de données corrompues.
Testez :
- L’intégrité des données migrées : les soldes comptables sont-ils corrects ? Les stocks correspondent-ils ?
- Les liens entre données : une commande en cours référence-t-elle le bon client, le bon article, le bon tarif ?
- Les doublons : la migration a-t-elle dédoublonné les fiches clients et fournisseurs ?
- La complétude : tous les champs obligatoires du nouveau système sont-ils renseignés ?
Prévoyez au minimum deux dry runs (répétitions à blanc) de la migration complète avant le go-live réel.
Gérer les anomalies, prioriser, tracer, corriger
Classification des anomalies
Toutes les anomalies n’ont pas le même poids. Utilisez une classification à trois niveaux :
- Bloquante : le processus métier ne peut pas aboutir. Exemple : impossible de valider une facture, calcul de TVA erroné, données perdues lors d’un flux. Le go-live est impossible tant qu’une anomalie bloquante reste ouverte.
- Majeure : le processus fonctionne mais avec un contournement pénible ou un risque d’erreur. Exemple : un état de rapprochement bancaire nécessite un export manuel intermédiaire. Le go-live est possible, mais la correction doit intervenir dans les 2 semaines suivantes.
- Mineure : inconfort d’utilisation sans impact métier. Exemple : un libellé mal traduit, un tri par défaut inadapté. Correction planifiable dans un lot ultérieur.
Outils de suivi
Pour une PME, un tableur structuré suffit à condition qu’il soit partagé et mis à jour quotidiennement. Colonnes essentielles : ID anomalie, date, module, scénario de test, description, sévérité, responsable correction, statut, date de résolution.
Pour une ETI, un outil de suivi dédié (Jira, Azure DevOps, ou le module incident de l’ERP lui-même) apporte la traçabilité nécessaire et facilite le reporting au comité de pilotage.
L’essentiel : chaque anomalie a un propriétaire et une date cible de correction. Pas d’anomalie orpheline.
Critères de go/no-go
Le go/no-go n’est pas un vote à main levée. C’est une décision basée sur des critères objectifs définis avant le début de la recette :
- Anomalies bloquantes ouvertes = 0 (non négociable)
- Anomalies majeures ouvertes < seuil défini (typiquement 3-5, avec contournement documenté pour chacune)
- Taux de couverture des scénarios de test > 95 % (tous les scénarios critiques exécutés)
- Reprise de données validée par le métier (soldes vérifiés, données de référence correctes)
- Key users formés et opérationnels (pas juste “informés”, capables d’utiliser le système seuls)
Si un seul de ces critères n’est pas rempli, le go-live est reporté. C’est coûteux, mais infiniment moins qu’un go-live raté.
Checklist go-live, les 10 points à valider avant de basculer
- Tous les scénarios UAT critiques sont passés OK, avec PV signé par les key users
- Zéro anomalie bloquante ouverte, les majeures restantes ont un contournement documenté
- Reprise de données validée, dry run final exécuté avec succès, soldes vérifiés
- Environnement de production prêt, serveurs dimensionnés, accès configurés, licences activées
- Plan de formation exécuté, chaque utilisateur a été formé sur ses processus (pas une démo générale)
- Supports utilisateurs disponibles, fiches réflexes, guides rapides, FAQ par processus
- Organisation du support post-go-live définie, qui répond aux questions ? Quel SLA pendant les 2 premières semaines ?
- Interfaces externes testées, banque, EDI fournisseurs, e-commerce, plateforme de facturation électronique
- Plan de rollback documenté, procédure de retour arrière testée, avec point de non-retour identifié
- Validation formelle du comité de pilotage, PV de go signé, responsabilités clarifiées
Validation métier signée par les key users
Le PV de recette n’est pas une formalité administrative. C’est l’engagement des key users que le système est conforme à leurs besoins validés en atelier. Chaque key user signe pour son périmètre fonctionnel. S’il refuse de signer, c’est qu’il reste des points à traiter, et c’est exactement le rôle du PV que de les rendre visibles.
Plan de rollback documenté
Même avec une recette impeccable, le plan B doit exister. Documentez :
- La procédure de retour à l’ancien système (restauration de base, réactivation des accès, bascule des flux)
- Le point de non-retour (typiquement : dès que les premières transactions de production sont enregistrées dans le nouvel ERP)
- Le délai de rollback (idéalement < 4 heures pour les processus critiques)
- Les responsables de la décision de rollback et le circuit d’escalade
Erreurs fréquentes en recette ERP
Tester avec des données trop propres. Des jeux de données artificiels masquent les problèmes qui apparaîtront avec les données réelles : caractères spéciaux, champs vides, historiques incohérents, doublons. Utilisez un extrait anonymisé de vos données de production.
Ne pas impliquer les utilisateurs finaux. Si seuls les consultants et l’IT testent, la recette valide la technique, pas l’usage. Les key users détectent les problèmes que les spécifications ne mentionnent pas : un écran trop lent pour la cadence de saisie en entrepôt, un processus de validation qui ajoute 3 clics inutiles.
Commencer la recette trop tard dans le planning. La recette représente typiquement 20 à 30 % de l’effort total du projet. Si elle est compressée dans les deux dernières semaines, vous testez sous pression, vous classez les anomalies majeures en “mineures” pour tenir le planning, et vous prenez la décision de go-live sous contrainte. Prévoyez 4 à 8 semaines pour une PME, 3 à 6 mois pour une ETI.
Confondre “ça marche” et “c’est validé”. Un test qui fonctionne techniquement ne signifie pas qu’il est conforme au besoin métier. Le résultat doit être vérifié par le key user, pas seulement par l’intégrateur.
Ne pas tester les cas d’exception. Les 80 % de flux standards fonctionnent souvent bien dès les premiers tests. Ce sont les 20 % restants (avoirs, retours partiels, commandes multi-devises, clôtures d’exercice) qui génèrent les crises post-go-live.
Négliger les tests de performance. Un système qui répond en 2 secondes avec 5 utilisateurs peut mettre 45 secondes avec 50 utilisateurs simultanés. Testez avec la charge réelle prévue, pas avec votre équipe projet seule.
Pour aller plus loin
La recette ERP ne s’improvise pas, elle se prépare comme un projet dans le projet. Si vous êtes en phase de cadrage, consultez notre guide pour rédiger un cahier des charges ERP qui inclut une section dédiée aux exigences de recette. Pour comprendre comment la recette s’inscrit dans le planning global, lisez notre article sur les 5 phases d’un projet ERP réussi. Et si vous voulez éviter les pièges qui mènent à une recette bâclée, notre analyse des erreurs qui font échouer un projet ERP complète le tableau.
Téléchargez notre grille d’évaluation des intégrateurs ERP, 10 critères sur 100 points pour comparer 3 intégrateurs et structurer votre décision.
