ERP : Odoo et Dolibarr 4 min

Cahier des charges ERP : le modèle court qui suffit

Un bon cahier des charges ERP décrit les flux de l'entreprise (du devis au paiement), les règles métier non négociables, les données à reprendre, les outils à relier, les volumes et les critères d'acceptation. Il tient en une quinzaine de pages et laisse au prestataire le choix des modules.

Sommaire11
  1. 01Le plan en sept sections
  2. 021. Le contexte
  3. 032. Les flux
  4. 043. Les règles métier
  5. 054. Les données
  6. 065. Les intégrations
  7. 076. Les volumes
  8. 087. L’acceptation
  9. 09Ce qu’il faut écrire en plus : le hors périmètre
  10. 10Le faire valider
  11. 11Questions fréquentes

Beaucoup de cahiers des charges ERP sont des listes de fonctions recopiées depuis les brochures des éditeurs : « gestion des stocks multi-entrepôts », « tableaux de bord personnalisables ». Tous les ERP cochent ces cases. Le document ne dit rien de ce qui rend votre entreprise particulière, et c’est pourtant là que les projets se jouent.

En bref

  • Décrivez des flux et des règles, pas des fonctions.

  • Visez une quinzaine de pages, lisibles par la direction et par les équipes.

  • Listez ce qui reste hors périmètre : c’est ce qui protège le budget.

  • Donnez des volumes réels et des critères d’acceptation testables.

Le plan en sept sections

  1. Le contexte

    Activité, effectif, sociétés, sites, outils en place.

  2. Les flux

    Du premier contact au paiement, et de la commande fournisseur à la réception.

  3. Les règles métier

    Ce qui ne se négocie pas.

  4. Les données

    Ce qu’on reprend, d’où, et dans quel état.

  5. Les intégrations

    Les outils qui restent et ce qu’ils échangent.

  6. Les volumes

    Utilisateurs, pièces par mois, références, entrepôts.

  7. L’acceptation

    Les scénarios qui prouvent que c’est fini.

1. Le contexte

Une page suffit. Qui êtes-vous, combien de personnes vont se connecter, dans combien de sociétés et de pays, avec quels outils aujourd’hui ? Ajoutez la raison du projet, en une phrase mesurable : « réduire la clôture mensuelle de cinq jours à deux », « arrêter les ressaisies entre le CRM et la facturation ». Les mesures de Quand passer à un ERP servent ici.

2. Les flux

C’est la section qui compte le plus. Pour chaque flux, écrivez les étapes, qui les fait et quelle pièce en sort. Par exemple : le commercial fait le devis, l’administration des ventes le transforme en commande après acompte, l’entrepôt prépare, la livraison déclenche la facture. Un schéma simple vaut mieux qu’un long texte.

Décrivez le flux tel qu’il devrait être, pas tel qu’il est avec ses contournements. Le projet ERP est le bon moment pour supprimer une étape inutile.

3. Les règles métier

Les remises autorisées par niveau, les conditions de paiement par type de client, la gestion des lots ou des numéros de série, les validations obligatoires au-delà d’un montant. Ce sont ces règles qui distinguent un paramétrage d’un développement. Notez pour chacune si elle est légale, contractuelle ou simplement une habitude : seules les deux premières sont vraiment non négociables.

4. Les données

Listez les données à reprendre (clients, fournisseurs, articles, tarifs, stocks, factures ouvertes, historique) et leur source. Soyez honnête sur leur état : doublons, champs vides, codes incohérents. La reprise des données est souvent le poste le plus sous-estimé.

5. Les intégrations

Quels outils restent ? Le logiciel de l’expert-comptable, la boutique en ligne, l’outil de paie, la banque. Pour chacun, dites ce qui doit circuler, dans quel sens et à quelle fréquence. Voir Connecter un ERP aux outils déjà en place.

6. Les volumes

Nombre d’utilisateurs par rôle, de devis, commandes et factures par mois, de références articles, d’entrepôts. Ces chiffres dimensionnent l’hébergement et le coût de licence. Ils évitent aussi les mauvaises surprises : un import de 50 000 références ne se traite pas comme un import de 500.

7. L’acceptation

Écrivez cinq à dix scénarios de bout en bout : « un client grand compte commande 200 pièces dont 50 en rupture ; la commande est partiellement livrée ; la facture porte uniquement le livré ». Le projet est fini quand ces scénarios passent. C’est la meilleure protection contre un projet qui ne se termine jamais.

Ce qu’il faut écrire en plus : le hors périmètre

Une liste explicite de ce que le projet ne fait pas : la paie, la fabrication, le site marchand, une deuxième société. Elle protège le budget et la date. Un périmètre qui grossit en cours de route est la première cause d’échec, détaillée dans Pourquoi un projet ERP échoue.

Pour s’inspirer des processus standard d’un ERP, la documentation d’Odoo décrit flux par flux ce que font les applications.

Le faire valider

Un cahier des charges n’a de valeur que s’il est validé par ceux qui vivent les flux. Faites relire chaque section par le responsable du service concerné, puis l’ensemble par la direction, et notez les désaccords plutôt que de les lisser : ce sont eux que le cadrage doit trancher. Le guide complet de l’ERP replace ce document dans l’ensemble du projet. Le cadrage de notre offre CRM et ERP produit ce document avec vous, en quelques ateliers, avant de proposer un outil et un prix fixe.

Questions fréquentes

Faut-il un consultant pour rédiger le cahier des charges ?

Pas forcément. Les personnes qui vivent les flux sont les mieux placées pour les décrire. Un regard extérieur aide surtout à séparer les vraies règles métier des habitudes et à poser les bonnes questions sur les volumes et les intégrations. Le cadrage de notre offre sert exactement à cela.

Doit-on choisir le logiciel avant d’écrire le cahier des charges ?

Non, c’est l’inverse. Le cahier des charges sert à comparer les logiciels sur votre réalité. Choisir l’outil d’abord revient à adapter l’entreprise à une démonstration, et à découvrir les écarts pendant le projet, au moment où ils coûtent le plus cher.

Quelle longueur viser ?

Une quinzaine de pages, schémas compris. Au-delà, personne ne relit le document en entier, et les contradictions passent inaperçues. Mieux vaut un document court que la direction et les équipes ont vraiment validé qu’un document exhaustif que personne n’a lu.

Sources

  1. Documentation des applications d’Odoo (nouvel onglet)odoo.com
Source 1

Documentation des applications d’Odoo

Lire sur odoo.com(nouvel onglet)

Jim · fondateur de Brain Plus AI

À lire aussi en erp : odoo et dolibarr

  • Guide pratique5 min Le guide du sujet

    ERP pour une entreprise de 20 à 500 personnes : le guide

    Un ERP réunit ventes, achats, stocks et facturation dans une seule base. Ce guide dit quand il devient utile, comment choisir entre Odoo et Dolibarr, et ce qui fait réussir ou échouer le projet.

  • Comprendre4 min

    Pourquoi un projet ERP échoue, et comment l’éviter

    Les projets ERP qui déraillent ne butent presque jamais sur le logiciel, mais sur le périmètre, les données, la personnalisation et l'adoption. Six causes, et la parade de chacune.

  • Choisir et chiffrer4 min

    Choisir un intégrateur ERP : les questions qui trient

    Tous les intégrateurs promettent un projet réussi. Quelques questions précises, sur la méthode, les données, la personnalisation et l'après, font la différence entre deux propositions.

WhatsApp