Regle production propale avant-vente

# Référentiel de règles — Avant-vente Odoo (EdooIt)

> **Objet.** Ce document compile les règles à appliquer à **chaque nouvelle avant-vente** (chaque nouveau sous-dossier de `EDOOIT-AVV`), afin de produire une **proposition commerciale professionnelle, cohérente, complète, engageante, claire et proactive** — **sans coût caché, sans tâche esquivée, sans demande client ignorée.**

> **Comment l'utiliser.** Pas de copie de fichier par dossier : (1) se référer directement au **gabarit de brief (Annexe A)** — les informations manquantes sont demandées à Nandrianina dans la discussion au moment de rédiger l'offre, (2) rédiger la proposition en suivant la structure et les règles ci-dessous, (3) dérouler la **checklist qualité (Annexe B)** directement depuis ce fichier avant tout envoi, et signaler dans la discussion tout point non conforme.

> Règles dégagées de 11 avant-ventes réelles : ADEFI, Aigle d'Or, CCIFM, CICM, EPIC, GlobalPOS, HERi, PAOSITRA Finance, Sakamanga, Stephaina, Victoria O.I.

> *Fichier unique — fusionne les anciens fichiers séparés (règles, gabarit de brief, checklist qualité, référentiel Word) le 21/09/2026, doublons supprimés. Seule source de règles utilisée : aucune skill Claude n'est plus utilisée en complément (décision du 21/09/2026).*

---

## 0. Principes directeurs (l'esprit avant la lettre)

1. **Rien d'ignoré.** Toute demande exprimée par le client (CR de réunion, CDC, mail, questionnaire, appel d'offres) doit être **explicitement traitée** dans l'offre : soit incluse au périmètre, soit placée en option/phase ultérieure, soit exclue — mais **jamais passée sous silence**. Une demande non retenue est nommée *et* justifiée.

2. **Zéro coût caché.** Tout ce qui coûte de l'argent est **nommé** : prestation forfaitaire, licences Odoo, hébergement, matériel, reprise d'historique, crédits à l'usage (OCR…), déplacements, TMA. On distingue toujours **forfait / récurrent / à la charge du client**.

3. **Engagement de résultat au forfait.** L'offre est un **forfait** avec **livrables définis et testés**, pas de la régie. Formule récurrente : *« budget maîtrisé dès le premier jour, sans surcoût masqué »*.

4. **Standard Odoo d'abord.** Configuration avant personnalisation ; **aucun développement spécifique sans ROI documenté**. Quand du spécifique est nécessaire, on le dit en toute transparence.

5. **Posture d'expert, pas de simple paramétreur.** Chaque besoin est *challengé* au regard des bonnes pratiques métier et des capacités natives d'Odoo ; on **recommande** proactivement ce qu'Odoo permet au-delà du standard.

6. **Orientation bénéfice client.** On ne vend pas des modules, on vend ce que *« ça change »* : *« la direction voit… »*, *« 0 ressaisie »*, *« clôture accélérée »*. Cas d'usage concrets plutôt que listes de fonctionnalités sèches.

7. **Ancrage local Madagascar.** Conformité (PCG malgache/français, CNaPS/IRSA/OSTIE, CSBF/PCEC…), réalités terrain (coupures → mode offline/dégradé, onduleur), souveraineté des données quand demandée.

8. **Cohérence de bout en bout.** Les besoins → la réponse Odoo → les lots → le planning → le budget → les modalités doivent **se correspondre exactement** (mêmes modules, mêmes durées, mêmes montants).

9. **Dimensionnement au juste besoin.** Ne proposer que les modules strictement nécessaires au besoin exprimé — pas de sur-périmètre par réflexe de bundle (ex. : un besoin de *suivi de stock* n'implique pas automatiquement le module Achats). Tout module ajouté au-delà du besoin explicite doit être justifié et signalé comme option, jamais intégré silencieusement au forfait de base.

---

## 1. Cycle de l'avant-vente (ce qui précède et entoure la proposition)

**Règle 1.1 — Compte-rendu (CR) systématique après chaque réunion**, envoyé sous **2 à 3 jours ouvrés**. Structure standard constante :

**Règle 1.2 — Le CR capture explicitement les *besoins spécifiques / points d'attention*** relevés en séance. Ce sont eux qui deviennent, dans la proposition, une section dédiée et/ou des options (ex. Victoria : facturation secteur public, WMS, OCR → repris à l'identique dans l'offre).

**Règle 1.3 — Brief commercial interne** (gabarit type GlobalPOS) = **input de la proposition**. Il **sépare** les données internes (charges en J/H, TJM, marge, budget interne) — *« usage interne uniquement, ne figurent pas dans la proposition finale »* — des éléments destinés au client.

**Règle 1.4 — Chiffrage interne en J/H × TJM, restitué au client en forfait.** Le détail J/H par rôle (CP / BA / Dev) reste interne ; le client voit un montant forfaitaire par lot.

**Règle 1.5 — Traçabilité besoin → offre.** Tenir un tableau de correspondance : *chaque* besoin (avec sa source) est relié à une réponse Odoo, un statut (inclus / option / phase 2 / hors périmètre) et un lot.

**Règle 1.6 — Sécuriser le chiffrage par le terrain.** Quand des inconnues pèsent sur le prix (nb de sites, matériel, volumétrie, format d'export), proposer une **descente sur site / un audit préalable** et l'annoncer, plutôt que de deviner (Stephaina « constats de terrain », EPIC « audit de reprise impératif »).

**Règle 1.7 — Brief (Annexe A) utilisé en référence directe, sans copie systématique.** Les informations du brief (contexte client, périmètre pressenti, contraintes, budget indicatif…) sont soit déjà connues (mail, CR, échange), soit demandées à Nandrianina dans la discussion au moment de rédiger l'offre. Pas de fichier `Brief_Avant-Vente_<Client>.md` créé par défaut dans le sous-dossier. *(Évolution du 21/09/2026 : remplace l'obligation de copie systématique introduite le même jour — la copie physique reste possible si Nandrianina la demande explicitement pour un dossier particulier.)*

**Règle 1.8 — Checklist (Annexe B) déroulée en fin de rédaction, sans copie systématique.** Avant l'envoi d'une offre, vérifier chaque point de l'Annexe B directement depuis ce référentiel et signaler explicitement dans la discussion tout point non conforme. Pas de fichier `Checklist_Qualite_<Client>.md` créé par défaut dans le sous-dossier.

**Règle 1.9 — Questions de clarification au client en priorité (20 max) + call rapide ; étape bloquante au-delà de 20 % d'inconnus structurants** *(validée par Nandrianina le 07/10/2026)*. Dès l'analyse des intrants (CR, CDC, mail, AO), **avant de rédiger l'offre**, envoyer rapidement au client une liste de questions, pour confirmer la compréhension et lever les points qui structurent la charge.

- **20 questions maximum**, classées par priorité : d'abord les **inconnues structurantes** (dont la réponse fait varier la charge, le périmètre ou l'architecture : volumétrie, nombre de sites, sociétés et utilisateurs, reprise d'historique, intégrations, besoins spécifiques, paie, matériel, SaaS ou Odoo.sh), puis les **reformulations à confirmer** (« Nous avons compris que… Confirmez-vous ? »).

- Chaque question est **reliée à une ligne de la matrice de traçabilité** (Annexe A §4) et rédigée pour une réponse rapide (fermée ou à choix quand c'est possible).

- **Proposer systématiquement un call court** pour y répondre de vive voix, idéalement plutôt qu'un échange écrit.

- **Taux d'inconnus structurants** = nombre de besoins de la matrice portant une inconnue structurante non levée ÷ nombre total de besoins.

- **Plus de 20 % → étape bloquante** : pas d'offre ferme. Attendre les réponses ou le call ; à défaut, proposer un **audit / cadrage préalable chiffré** (Règle 1.6) avant l'offre de mise en œuvre.

- **20 % ou moins** : rédaction possible ; chaque inconnue restante devient une **hypothèse explicite** du forfait (Règle 3.4) ou un poste **« À chiffrer après audit »** (Règle 3.3).

---

## 2. Structure standard de la proposition commerciale

Ordre et contenus récurrents (adapter selon l'ampleur ; un connecteur technique est plus court qu'un ERP multi-lots). **Contenus à couvrir, pas une slide par rubrique : regroupement en 10 slides maximum (Règle 2.2).**

1. **Page de garde** — titre orienté valeur ; client destinataire ; prestataire (**EdooIt**) ; périmètre (lots/modules) ; durée ; **version Odoo** ; **responsable de l'offre** ; date d'émission ; **date de validité** ; n° de version (V1/V2…).

2. **Sommaire** — pour toute offre de plus de ~8 pages ; dans un deck de 10 slides, intégré au résumé exécutif (Règle 2.2).

3. **Résumé exécutif / Notre approche** — 4-6 lignes : enjeu, réponse, séquencement, différenciateur.

4. **Contexte & enjeux client** — présentation du client (secteur, taille, implantations), **problématiques identifiées**, objectifs business.

5. **Constat « avant / après »** — *ce qui bloque aujourd'hui* vs *ce qui est attendu* (le delta = le cahier des charges de l'offre).

6. **Problématiques chiffrées** — pour chaque friction, son **coût / impact** (erreurs, ruptures, clôtures longues…).

7. **Points d'attention / besoins spécifiques relevés en séance** — section explicite, tracée depuis le CR ; préciser inclus vs option.

8. **Périmètre — In Scope / Out of Scope** — deux colonnes claires, + **responsabilités réciproques** (EdooIt / client).

9. **La réponse Odoo, module par module** — *« Le flux dans Odoo »* (3 étapes numérotées) + *« Ce que ça change »* / *« La direction voit… »* + cas d'usage concrets ; chiffres d'impact.

10. **Vue « une seule base de données »** — l'intégration inter-modules, *« zéro double saisie »*, traçabilité de bout en bout.

11. **Focus différenciant** — 1 sujet d'expertise mis en avant (OCR fournisseurs, paie MG sans localisation, 25 états CSBF, connecteur/Proxy V2, mode offline…).

12. **Découpage en lots / phases** — par lot : périmètre, durée (semaines + jours), contenu, cas d'usage, **livrables**.

13. **Méthodologie / démarche par phases** — Kick-off → Onboarding → Réalisation/paramétrage → Recette (UAT) → Formation → Mise en production → Hypercare ; livrables par phase.

14. **Gouvernance** — équipe EdooIt (Directeur de projet, Chef de projet/SPOC, Business Analyst, Développeur) ; **référents client attendus** (sponsor, CP, key-users) ; **rituels** (point hebdo/COPROJ, COPIL, recette formalisée).

15. **Conditions de réussite — engagements réciproques** — *« ce que nous engageons »* / *« ce que nous demandons »* + **clause de décalage** : *« tout retard sur les prérequis se répercute sur le planning »*.

16. **Planning / macro-planning** — en semaines, avec **jalons** et **Go-Live** ; mentionner que la validation dépend de la disponibilité des équipes.

17. **Livrables par lot & hypothèses** — récapitulatif.

18. **Offre financière** — tableau forfaitaire par lot, **HT**, devise explicite, **TOTAL** ; *« À chiffrer après audit »* pour l'in-cadrable ; libellé *« enveloppe forfaitaire globale sans dépassement »*.

19. **Modalités de paiement adossées aux jalons** livrés et validés (acompte de mobilisation + jalons).

20. **Validité de l'offre** — date ferme + effet du dépassement.

21. **Garantie & TMA / support** — garantie incluse (durée) ; packs TMA à niveaux ; **SLA/GTP par priorité** ; ticketing + SPOC ; heures/mois + report du solde ; *« au-delà du forfait → avenant »*.

22. **Licences & hébergement** — présentés **à titre indicatif**, **facturés directement par Odoo**, **distincts de la prestation** ; simulation (X utilisateurs, stockage) ; avantages Odoo.sh ; remise 1ʳᵉ année.

23. **Phases d'évolution / hors offre** — roadmap présentée *« à titre informatif, à chiffrer après audit »* (montre la vision sans gonfler le prix).

24. **Qui sommes-nous** — EdooIt ; **Partner Odoo** (ne pas mentionner « Gold » pour l'instant, consigne du 07/10/2026) ; +20 ans / +650 projets / +350 experts ; **références proches** du secteur.

25. **Ils nous font confiance** — logos / références clients.

26. **Validation & démarrage** — *« Bon pour accord »*, signataires **des deux côtés** (nom + fonction), **contact dédié** (nom, fonction, email, téléphone), next steps concrets.

**Règle 2.1 — Corps principal resserré, détails structurants en annexe** *(validée par Nandrianina le 06/10/2026, dossier IBS Burkina / Atos)*. L'offre reste **complète** (rien n'est supprimé), mais le corps principal **va à l'essentiel** : il déroule sans détour *besoin → réponse → périmètre → lots et planning → **prix** → validation*, de sorte que le lecteur soit cadré jusqu'au prix dès les premières slides.

- **Restent dans le corps** : page de garde, sommaire, résumé exécutif, contexte et avant/après, périmètre recentré, In/Out, responsabilités, vue des lots (sans détail), focus différenciant, transverses (une seule base, conformité, offline), démarche, gouvernance, engagements, macro-planning, **offre financière** (prix, jalons de paiement, tous les coûts, licences, TMA), roadmap, réversibilité, qui sommes-nous, validation.

- **Passent en annexes numérotées (A1, A2…)**, après la page de validation et derrière une page de garde « Annexes » qui les liste : points d'attention du CDC / du CR, réponse ligne à ligne (synthèse de la matrice), détail lot par lot et flux « dans Odoo », tableau natif vs spécifique, livrables et hypothèses du forfait, risques et parades.

- **Référencer** : chaque slide du corps qui s'appuie sur un détail renvoie explicitement à l'annexe (« détail : annexe A4 », « réponse ligne à ligne : annexe A3 et matrice Excel jointe »), dans le sous-titre ou l'encadré de bas de slide ; le sommaire comporte une rubrique « Annexes ».

- **Prix** : présent uniquement dans la section « Offre financière » du corps principal (offre financière, paiement, tous les coûts, licences, TMA) — **ni dans le résumé exécutif, ni sur la vue des lots, ni dans les annexes** ; le résumé exécutif met en avant couverture, délais et approche.

**Règle 2.2 — 10 slides maximum, zéro redondance, zéro superflu** *(validée par Nandrianina le 07/10/2026)*. Les 26 rubriques ci-dessus sont des **contenus à couvrir, pas une slide chacune** : elles sont regroupées dans un corps principal de **10 slides au plus**, de la page de garde à la validation.

- **Trame cible en 10 slides** :

1. Page de garde (titre, client, version Odoo, responsable, émission, validité, n° de version)

2. Résumé exécutif, avec le sommaire intégré

3. Contexte, enjeux et constat avant/après (problématiques chiffrées, points d'attention → annexe)

4. Réponse Odoo et périmètre : In/Out, responsabilités, vue « une seule base »

5. Focus différenciant (+ conformité locale, offline, TDB natifs si pertinent)

6. Lots, livrables et macro-planning (jalons, Go-Live, roadmap des phases ultérieures à titre informatif)

7. Démarche, gouvernance et engagements réciproques (clause de décalage)

8. Offre financière : forfait par lot, TOTAL, jalons de paiement, validité

9. Coûts récurrents et à la charge du client : licences, hébergement, garantie et TMA, matériel, déplacements

10. Qui sommes-nous, références, validation (bon pour accord, signataires, contact) et next steps

- **Une information n'apparaît qu'une fois** dans le corps : pas de récapitulatif qui répète un tableau, pas de slide de transition ou d'intercalaire (seule exception : la page de garde « Annexes »), pas de description générique de module.

- **Test de chaque slide** : si on la retire, le client perd-il quelque chose dont il a besoin pour décider ? Si non, on la supprime ou on la passe en annexe. Deux slides peu remplies sur un même thème sont fusionnées.

- **Annexes** (Règle 2.1) : strict nécessaire, chacune référencée depuis le corps, sans reprendre ce que le corps dit déjà.

- **Au-delà de 10 slides de corps** : avant de générer, **demander à Nandrianina** si c'est vraiment nécessaire, en listant les slides supplémentaires et leur justification. Ne rien ajouter sans son accord. Une offre courte (connecteur, mono-domaine) peut tenir en moins de 10.

---

## 3. Règles « zéro coût caché »

**Règle 3.1 — Tout coût est nommé et catégorisé.** Trois familles à toujours distinguer :

| Famille | Contenu | Traitement |

|---|---|---|

| Forfait de prestation | L'objet de l'offre | Engagé, ferme |

| Récurrent | Licences Odoo, hébergement, TMA, infogérance | Facturé par Odoo / abonnement — hors prestation |

| À la charge du client | Matériel, serveur, données sources, réseau/postes | Nommé explicitement |

**Règle 3.2 — La liste des coûts « faciles à oublier »** à vérifier systématiquement :

- **Licences Odoo Enterprise** (avec simulation + remise 1ʳᵉ année).

- **Hébergement** (Odoo.sh / on-premise) avec simulation utilisateurs + stockage.

- **Matériel** : lecteurs biométriques/pointeuses (ex. ZKTeco MB360), terminaux, imprimantes tickets, tiroirs-caisse, serveur — **à la charge du client**, préciser où l'acheter si connu.

- **Reprise / migration d'historique** (Sage, EPB…) : **chiffrée séparément** après analyse du format d'export et de la volumétrie ; distinguer **référentiels** (souvent inclus) vs **historiques de transactions** (hors, en sus).

- **Crédits à l'usage** : OCR facturé à l'usage par Odoo (crédits par lot).

- **Frais de déplacement / hébergement hors Antananarivo** : à la charge du client, facturés en sus.

- **Développements spécifiques** non natifs : identifiés, chiffrés ou renvoyés à l'audit.

- **TMA / support au-delà de la garantie** ; heures au-delà du forfait → **avenant**.

- **Infogérance** (si hébergement VPS alternatif à Odoo.sh, cf. Règle 5.9) : à chiffrer comme prestation récurrente EdooIt, distincte du forfait initial.

**Règle 3.3 — « À chiffrer après audit » est un engagement, pas une échappatoire.** On ne l'emploie que pour l'in-cadrable, en précisant **l'audit qui produira le chiffre** et **quand**.

**Règle 3.4 — Hypothèses explicites.** Le forfait tient *sous conditions* : disponibilité des référents, fourniture des données d'entrée en semaine 1, périmètre au standard, matériel fourni par le client, un seul cycle de paie à blanc, etc. Les lister.

---

## 4. Règles « aucune tâche esquivée » (complétude & sérieux d'exécution)

**Règle 4.1 — In Scope ET Out of Scope, toujours les deux.** Le hors-périmètre est aussi important que le périmètre : il évite l'ambiguïté et les litiges.

**Règle 4.2 — Responsabilités réciproques explicites.** Ce qu'EdooIt fait / ce que le client fournit (extractions, serveur, accès, environnement de pré-prod, key-users).

**Règle 4.3 — Recette et validation formalisées.** Procès-verbal de recette signé jalon par jalon ; délai de réserve (ex. 7 jours ouvrés → réputé accepté). *« Documentation remise avant chaque mise en production, pas après. »*

**Règle 4.4 — Formation sur données réelles**, pas sur un jeu de démonstration ; support bâti sur les *« pains »* réels du client.

**Règle 4.5 — Reprise de données : 4 lots types, prérequis et risques vérifiés avant chiffrage ferme, contrôle de balance systématique.** Découpage standard : **Cadrage** (extraits complets sur toute la période + mapping comptes/analytique + test de la clé de rapprochement/lettrage) → **Transformation & import** (script, création des écritures + réconciliation) → **Test & recette** (import en environnement de **test**, **contrôle croisé automatique des balances source/Odoo**, écart attendu = 0, recette écrite du client) → **Bascule finale** (sauvegarde préalable, import **production**, vérification finale, **note de clôture**). Avant tout chiffrage ferme, sécuriser les prérequis (accès Odoo test **et** prod avec droits API adéquats, extraits complets sur toute la période, correspondance des journaux établie, exercices/périodes non verrouillés) et nommer les risques (devises non couvertes par l'estimation, déverrouillage d'exercice à négocier, volume de cas particuliers inconnu avant test, droits API insuffisants). Pour une reprise ponctuelle, un script jetable avec mapping en dur suffit — pas de module réutilisable à développer (cf. Principe 9). Livrables : plan de migration, scripts/fichiers d'import, rapport de contrôle des balances, note de clôture. *Gabarit de chiffrage détaillé (hypothèses, charges par lot) : Annexe E.11.*

**Règle 4.6 — Accompagnement post-MEP nommé** : garantie (X mois/heures), puis bascule TMA ; hypercare au go-live.

---

## 5. Règles d'expertise Odoo & spécificités Madagascar (à réutiliser tel quel)

**Règle 5.1 — Paie Madagascar : pas de localisation standard.** Odoo ne fournit **aucune localisation de paie pour Madagascar**. Les règles **IRSA, CNaPS, OSTIE** (et mutuelles) se construisent en **règles de paie paramétrables** = **configuration (données), pas du code** → **réalisable sur SaaS/Odoo Online**. **Limite SaaS** : les **états déclaratifs officiels** (CNaPS, OSTIE, IRSA au format administratif) et les **formats de fichiers de virement bancaires malgaches** peuvent exiger des rapports sur mesure → **Odoo.sh** (phase ultérieure). Prévoir un **run de paie à blanc** avant go-live.

**Règle 5.2 — Banques malgaches : pas de synchro bancaire automatique.** Alimentation par **import de relevés** (CSV, OFX, QIF, CAMT.053) ; **un mapping par banque** (BNI, BOA, BFV-SG, BMOI…) → **charge dédiée** à l'import multi-banques. Utiliser les **reconciliation models** pour automatiser le lettrage récurrent.

**Règle 5.3 — Optimisation des licences via le Portail (gratuit).** Congés, notes de frais, consultation des bulletins pour N employés via **utilisateurs portail (gratuits)** ; seules les personnes qui opèrent le back-office prennent une licence interne. Compléter par **alias e-mail** pour la saisie mobile des notes de frais.

**Règle 5.4 — SaaS vs Odoo.sh : le bon arbitrage.** SaaS = 100 % configuration, ni code ni module custom. Odoo.sh = code, **environnement de staging**, versioning Git. Règle : livrer en **configuration pure sur SaaS** quand l'échéance presse, **basculer vers Odoo.sh** en même temps que le premier vrai besoin de spécifique / la migration de version — **mutualiser une seule bascule**.

**Règle 5.5 — Reprise vs implémentation.** Quand Odoo est **déjà en place**, **reprendre l'existant** plutôt que repartir de zéro (audit du paramétrage en semaine 1) ; distinguer les **données nécessaires au démarrage** de celles injectables en cours de route.

**Règle 5.7 — Réalités terrain.** Multi-sites + coupures → **mode offline/dégradé** (POS), synchro au rétablissement ; moyens de paiement locaux (espèces, MVola, Orange Money, carte, virement) ; onduleur recommandé ; hébergement **on-premise / souveraineté** quand exigé (secteur public, régulé).

**Règle 5.8 — Conformité sectorielle.** Adapter au régulateur : **PCG 2005 / PCG français**, **CSBF + PCEC** (microfinance) avec états mensuels, circuits d'approbation auditables, etc.

**Règle 5.9 — Alternative d'hébergement si Odoo.sh est bloquant côté budget.** Quand le coût Odoo.sh freine la décision du client, proposer un **VPS / serveur cloud dédié + offre d'infogérance EdooIt** (installation, monitoring, sauvegardes, mises à jour, sécurité) en remplacement. Argument commercial : un **serveur on-premise coûte largement plus cher** qu'un VPS (investissement matériel, maintenance, disponibilité, personnel dédié) — le VPS + infogérance EdooIt combine flexibilité cloud et coût maîtrisé, sans les limites d'un hébergement 100 % on-premise.

**Règle 5.10 — Tableaux de bord (TDB) : la règle du natif** *(validée par Nandrianina le 07/10/2026)*. Un indicateur ou un TDB est **natif**, donc inclus au forfait sans réserve, s'il remplit **les 3 conditions** :

1. **Donnée déjà présente en base** : elle est saisie ou générée par les flux du périmètre et stockée dans un champ existant. Pas de recalcul ni de requête spécifique par code (pas de SQL, pas de vue SQL, pas de champ calculé ajouté).

2. **Restituée avec les vues natives Odoo** : tableau croisé dynamique (pivot), graphique, liste groupée, cohorte, kanban, carte, Gantt, filtres, regroupements et favoris enregistrés, tableaux de bord natifs (app *Tableaux de bord* / Spreadsheet Enterprise construits à partir de ces vues).

3. **Sans Odoo Studio** : aucun champ, vue ou modèle ajouté par Studio. Studio est une option payante (abonnement Custom) qui fait sortir du standard.

**Principe de qualification : faisable en configuration = natif.** Tout ce qui se réalise par simple paramétrage de l'interface standard, sans code ni Studio (filtres, regroupements, mesures, favoris, formules Spreadsheet sur des pivots natifs, tableaux de bord composés), est qualifié **natif** et inclus au forfait. Il n'y a que deux statuts : **natif** ou **spécifique**.

Si l'une des conditions tombe, l'indicateur est **spécifique** : il est nommé, chiffré (ou renvoyé à l'audit) et classé dans le tableau natif vs spécifique, jamais promis implicitement comme natif (cf. Principes 1, 2 et 4).

Points de vigilance pour qualifier un KPI :

- **Champ stocké obligatoire** : un champ calculé non stocké ne peut servir ni de mesure ni de regroupement dans un pivot ou un graphe. Le rendre exploitable demande du code (donc spécifique, Odoo.sh).

- **Ratios et indicateurs croisés** (marge %, DSO, taux de rotation, écart budget/réel entre modules…) : vérifier s'ils existent déjà dans un rapport natif (rapports comptables, analyse des ventes/achats/stock). Sinon, une formule Spreadsheet sur des pivots natifs reste de la **configuration** (sans code ni Studio) : elle est **native** et listée nommément dans les livrables. Au-delà (requête, champ ou modèle nouveau), c'est du spécifique.

- **La donnée doit vraiment être saisie** : un KPI natif n'a de valeur que si le processus alimente le champ (ex. motif de perte CRM, centre analytique sur chaque pièce). Mettre la discipline de saisie dans les hypothèses du forfait (Règle 3.4) et les responsabilités client.

- **Données hors Odoo** (fichiers Excel, autre logiciel, historique non repris) : jamais natives. Elles passent par la reprise de données (Règle 4.5) ou un connecteur, chiffrés à part.

- **Droits d'accès** : un TDB montre ce que les droits de l'utilisateur permettent de voir. Un cloisonnement par site, équipe ou profil non couvert par les groupes et règles standard relève du spécifique.

Dans l'offre : lister les TDB livrés **par nom et par public** (« la direction voit… »), avec leur statut natif / spécifique, dans le détail lot par lot et le tableau natif vs spécifique (Règle 2.1). Proposer d'abord ce que le natif couvre (Règle 6.2) avant tout reporting sur mesure.

---

## 6. Règles de proactivité (ce qui rend l'offre engageante)

**Règle 6.1 — Proposer une roadmap d'évolution** (phases 2/3) même hors périmètre, *« à titre informatif, à chiffrer après audit »* : montre la vision et prépare le futur chiffre d'affaires sans alourdir l'offre.

**Règle 6.2 — Recommandations d'expert non sollicitées mais à ROI** : portail gratuit pour économiser des licences, paiements par lot (batch), plans de relance multi-niveaux, reconciliation models, timing de bascule Odoo.sh, choix du plan Odoo (Standard vs Custom).

**Règle 6.3 — Next steps concrets** en clôture : signer le bon pour accord, planifier le kick-off, lancer la collecte des données d'entrée — avec dates.

**Règle 6.4 — Un différenciateur mis en avant** par offre (le « focus »), pour ancrer la valeur et se distinguer d'un concurrent.

---

## 7. Règles de forme, de ton et de cohérence

**Règle 7.1 — Ton** : clair, orienté bénéfice, expert et rassurant ; prose lisible, jargon justifié ; phrases d'impact chiffrées.

**Règle 7.2 — Devise & langue** : montants **HT**, en **Ariary (Ar / MGA)** pour les clients locaux, en **€ HT** pour l'offshore (France, Réunion, Mayotte) ; adapter au destinataire.

**Règle 7.3 — Identité** : **une seule marque, EdooIt** (Partner Odoo — pas de mention « Gold » pour l'instant) — depuis septembre 2026, toutes les offres sont émises au nom d'**EdooIt**, sans autre mention d'entité ; **footer récurrent** (prestataire · client · nom de l'offre + n° de page/slide).

**Règle 7.4 — Version & validité** : chaque offre porte un **n° de version**, une **date d'émission** et une **date de validité** ; préciser l'effet d'un dépassement de validité (tarifs révisables, planning recalé sur la date de signature).

**Règle 7.5 — Cohérence chiffrée (contrôle croisé)** : `somme des lots = total` ; `durées des lots = planning` ; `modules du périmètre = réponse Odoo = lots = budget` ; version Odoo, devise et dates identiques partout.

**Règle 7.6 — Confidentialité** : mention *« Confidentiel — [Client] »* / *« document commercial »* quand utile.

**Règle 7.7 — Signature & contact** : page de validation avec **signataires des deux parties** (nom + fonction) et **interlocuteur dédié** (nom, fonction, email, téléphone).

---

## 8. Modèles de conditions commerciales réutilisables

**Paiement — adossé aux jalons livrés et validés.** Schéma type : **acompte de mobilisation** (20 % à la signature, pour réserver l'équipe) puis **jalons** (cadrage / livraison par lot sur environnement de qualification / go-live). Variantes observées : 40/20/20/20 (Victoria) ; 30/40/30 (GlobalPOS) ; 50/50 par module (CICM, Sakamanga, PAOFI) ; 100 % à la commande pour un audit court. *« Aucun paiement au calendrier au-delà de l'acompte ; le solde est conditionné aux jalons »* — argument fort face à un client exigeant.

**Garantie & TMA.** Garantie post-livraison incluse (1 à 2 mois, ou X heures gratuites). Puis TMA : maintenance corrective + support, **ticketing dédié + SPOC** des deux côtés, **horaires** (9h–12h30 / 13h30–18h), forfait mensuel d'heures **cumulable**, report du solde si renouvellement anticipé, **au-delà du forfait → avenant**, contrat annuel renouvelable.

**SLA / GTP par priorité :**

| Priorité | Définition | Prise en charge (GTP) |

|---|---|---|

| Critique / Bloquant | Exploitation empêchée | ≤ 2 h ouvrées |

| Important | Impactant, non bloquant | ≤ 4 h ouvrées |

| Normal / Mineur | Incident mineur / confort | 2 à 5 j ouvrés |

**Licences & hébergement.** Toujours **distincts de la prestation**, **facturés par Odoo**, présentés **à titre indicatif** avec une **simulation** (nb utilisateurs, stockage) et la **remise 1ʳᵉ année**. Rappeler les atouts Odoo.sh (surveillance 24/7, DNS/e-mail, réplication, backups, staging).

**Périmètre & avenants.** Toute évolution du périmètre → **avenant écrit chiffré avant exécution**.

---

## 9. Adaptation par type de projet (ne pas appliquer aveuglément)

| Type de projet | Ce qui change |

|---|---|

| ERP multi-lots (Victoria, CICM, ADEFI, EPIC) | Structure complète : lots + planning + gouvernance lourde. |

| Offre mono-domaine (Sakamanga RH, PAOFI Finance/CSBF) | Packs plus resserrés, focus métier fort. |

| Connecteur / développement technique (GlobalPOS) | SFD, architecture, backlog par tâche, recette Sandbox QA, garantie courte, publication Marketplace — chiffrage interne détaillé (J/H par rôle) reste **interne**. |

| Reprise d'existant (Stephaina) | Audit de reprise d'abord, planning « non engageant » tant que l'existant n'est pas relevé, jalons conditionnés au terrain. |

| Client offshore (Victoria, GlobalPOS) | Devise €, conformité française en plus (PCG FR, secteur public). |

---

## Annexe A — Gabarit de brief (à copier dans chaque nouveau sous-dossier)

> À remplir avant de rédiger la proposition. Il concentre les intrants et sert de source unique. Champs `[à compléter]`. Les sections marquées **🔒 INTERNE** ne figurent **jamais** dans l'offre remise au client.

### 0 · Identité du dossier

- **Client :** [à compléter]

- **Projet / intitulé :** [à compléter]

- **Entité émettrice :** EdooIt (seule marque utilisée sur les offres).

- **Responsable de l'offre :** [nom · fonction · email · tél]

- **Mois de soumission :** [à compléter] · **Version offre :** V[ ] · **Validité visée :** [date]

- **Version Odoo cible :** [17 / 19] · **Édition : Enterprise** (seule édition proposée)

- **Hébergement cible :** Odoo Online (SaaS) ☐ / Odoo.sh ☐ / On-premise ☐

- **Devise :** Ar (MGA) ☐ / € ☐

### 1 · Intrants reçus (lister TOUS les documents + date)

|---|---|---|---|

### 2 · Compréhension du client

- **Secteur / activité :** [à compléter]

- **Taille / effectif / implantations :** [à compléter]

- **Existant (logiciel actuel, modules Odoo déjà en place) :** [à compléter]

- **Objectifs stratégiques / enjeux :** [à compléter]

- **Contraintes (souveraineté, calendrier ferme, budget, régulateur) :** [à compléter]

### 3 · Problématiques / « pains » (avec impact)

- [pain] → [ce que ça coûte aujourd'hui]

### 4 · Traçabilité des besoins — LE tableau anti-oubli

> Une ligne par besoin exprimé, quelle que soit sa source. **Chaque ligne doit avoir un statut.**

|---|---|---|---|---|---|---|---|

| 1 | [à compléter] | | | | | | |

- **Taux d'inconnus structurants non levés :** [x] % (seuil bloquant : 20 %, Règle 1.9)

- **Questions envoyées au client :** [nb ≤ 20] le [date] · **Call proposé :** [date] · **Réponses reçues :** [date]

### 5 · Périmètre

- **In Scope :** [modules / prestations]

- **Out of Scope :** [exclusions explicites]

- **Responsabilités EdooIt :** [à compléter]

- **Responsabilités client :** [extractions, serveur, accès, key-users, environnement pré-prod…]

### 6 · Points spécifiques, risques & expertise à activer

- Paie Madagascar (règles CNaPS/IRSA/OSTIE, run à blanc, états déclaratifs → Odoo.sh) ? ☐

- Banques MG (import relevés + mapping par banque) ? ☐ Banques concernées : [ ]

- Reprise/migration (source : [Sage/EPB/…], format export : [ ], volumétrie : [ ]) → référentiels inclus / historiques en sus ☐

- Matériel requis (biométrie, terminaux, imprimantes, serveur) → à la charge du client ☐

- Mode offline / dégradé nécessaire (multi-sites, coupures) ? ☐

- Développement spécifique identifié (avec justification ROI) : [à compléter]

- Tableaux de bord / KPI demandés → qualifiés natif / spécifique (Règle 5.10) ☐ Liste : [TDB · public · statut]

### 7 · Découpage en lots & chiffrage

**🔒 INTERNE — chiffrage :**

|---|---|---|---|---|

| | | | | |

**Restitution client (forfait) :**

| Réf | Lot | Périmètre | Montant HT |

|---|---|---|---|

| | | | |

- Éléments « À chiffrer après audit » : [lesquels + quel audit + quand]

### 8 · Planning & jalons

- Durée par lot (semaines / jours) : [à compléter] · **Go-Live visé :** [date]

- Jalons de paiement : [acompte mobilisation % + jalons]

- Contrainte calendaire client / date de signature critique : [à compléter]

### 9 · Conditions commerciales

- **Modalités de paiement (adossées aux jalons) :** [à compléter]

- **Garantie incluse :** [durée / heures]

- **TMA / support :** [formules, SLA, ticketing, forfait mensuel]

- **Licences :** simulation [X utilisateurs] + remise 1ʳᵉ année : [à compléter]

- **Hébergement :** [Odoo.sh / on-premise] — simulation : [à compléter]

- **Matériel / déplacements hors Tana :** à la charge du client ☐

### 10 · Références à citer & chiffres clés

- Références sectorielles proches : [à compléter]

- Chiffres clés EdooIt : +20 ans · +650 projets · +350 experts · Partner Odoo

- Signataires : [client : nom+fonction] / [EdooIt : nom+fonction]

---

## Annexe B — Checklist qualité (à valider AVANT tout envoi d'une proposition)

> Objectif : **rien d'ignoré, aucun coût caché, aucune tâche esquivée.** Ne pas envoyer tant qu'une case bloquante (⛔) n'est pas cochée.

### A · Complétude & traçabilité des demandes

- ⛔ Chaque besoin du CR / CDC / mail / questionnaire / AO a une ligne avec un **statut** (inclus / option / phase 2 / hors périmètre).

- ⛔ Questions de clarification envoyées au client (20 max, priorisées) et call rapide proposé ; taux d'inconnus structurants non levés ≤ 20 %, sinon pas d'offre ferme → audit/cadrage préalable (Règle 1.9).

- ⛔ Les **points spécifiques relevés en séance** ont une section dédiée dans l'offre.

- ⛔ Toute demande **non incluse** est **nommée ET justifiée** (jamais silencieuse).

- ☐ In Scope **et** Out of Scope présents ; responsabilités EdooIt / client explicites.

- ⛔ Le périmètre proposé correspond au juste besoin exprimé, sans module ajouté par réflexe de bundle (cf. Principe 9 — dimensionnement au juste besoin).

### B · Zéro coût caché

- ⛔ Licences Odoo Enterprise traitées (simulation + remise 1ʳᵉ année).

- ⛔ Hébergement (Odoo.sh / on-premise) chiffré ou simulé, **distinct de la prestation**.

- ⛔ Matériel (biométrie, terminaux, imprimantes, serveur) = **à la charge du client**, dit clairement.

- ⛔ Reprise / migration d'historique : chiffrée séparément (référentiels vs historiques distingués).

- ☐ Crédits à l'usage (OCR…) mentionnés ; déplacements hors Tana en sus ; dev spécifique identifié.

- ☐ TMA / heures au-delà du forfait → **avenant**.

- ⛔ Distinction **forfait / récurrent / à la charge du client** visible.

- ☐ « À chiffrer après audit » uniquement pour l'in-cadrable, **avec l'audit et le délai** associés.

- ⛔ Chaque TDB / KPI promis est qualifié **natif / spécifique** selon la Règle 5.10 (donnée stockée en base, vues natives, sans Studio ; faisable en configuration = natif) ; aucun reporting spécifique présenté comme standard.

### C · Cohérence (contrôle croisé)

- ⛔ Somme des lots = **TOTAL** affiché.

- ⛔ Durées des lots = **planning**.

- ⛔ Modules du périmètre = réponse Odoo = lots = budget (aucun module orphelin).

- ☐ Version Odoo, **devise** et **dates** identiques partout.

- ☐ Hypothèses / prérequis listés (référents, données S1, périmètre standard, matériel, run paie à blanc).

### D · Engagement & clarté

- ☐ Forfait + **engagement de résultat** affiché (« sans surcoût masqué »).

- ☐ Engagements réciproques + **clause de décalage planning**.

- ⛔ **Date de validité** présente ; effet du dépassement précisé.

- ⛔ Modalités de paiement **adossées aux jalons** (acompte de mobilisation + jalons).

### E · Proactivité & valeur

- ☐ Roadmap phases d'évolution (« à titre informatif, à chiffrer après audit »).

- ☐ Au moins une **recommandation d'expert à ROI** (portail gratuit, batch payments, relances, Odoo.sh…).

- ☐ Un **focus différenciant** mis en avant.

- ☐ **Next steps** concrets et datés en clôture.

### F · Local & conformité

- ☐ Conformité citée (PCG MG/FR, CNaPS/IRSA/OSTIE, CSBF/PCEC…).

- ☐ Paie MG : approche « configuration, pas code » + états déclaratifs → Odoo.sh, run à blanc.

- ☐ Banques MG : import relevés + mapping par banque (si compta/trésorerie).

- ☐ Mode offline / souveraineté traités si le contexte l'exige.

### G · Forme & finition

- ⛔ Page de garde complète (titre, client, prestataire, version Odoo, responsable, date, **validité**, n° version).

- ☐ Sommaire (intégré au résumé exécutif si deck ≤ 10 slides) ; footer/pagination récurrent ; marque cohérente (une seule entité).

- ⛔ Corps principal ≤ 10 slides, sinon ajout validé par Nandrianina ; aucune information répétée, aucune slide de transition ou superflue ; annexes réduites au strict nécessaire (Règle 2.2).

- ☐ « Qui sommes-nous » + références + « Ils nous font confiance ».

- ⛔ Page de validation : signataires **des deux côtés** + contact dédié (nom, fonction, email, tél).

- ☐ Relecture orthographe/chiffres ; PDF généré ; nom de fichier versionné et daté.

- ☐ Corps principal resserré jusqu'au prix ; détails structurants en annexes numérotées, référencées depuis le corps ; prix uniquement dans la section offre financière (Règle 2.1).

**Verdict :** toutes les ⛔ cochées → prêt à envoyer. Sinon → corriger avant envoi.

---

## Annexe C — Catalogue des modules & solutions déjà proposés

> Journal cumulatif : à chaque avant-vente traité, ajouter une ligne pour les modules/solutions proposés — utile pour repérer les patterns déjà chiffrés et déjà argumentés, réutilisables sur de futures offres. **Peut être enrichi directement, sans validation préalable** (contrairement aux règles, cf. Annexe D).

|---|---|---|---|

| Comptabilité générale & analytique | CICM, Stephaina, EPIC, Victoria, HERi | Plan comptable, rapprochement bancaire, clôture, conformité fiscale | Conformité PCG MG et/ou FR sur une seule base |

| RH & Paie Malagasy | CICM, Stephaina, Sakamanga, HERi | Cycle de paie IRSA/CNaPS/OSTIE, congés, contrats, recrutement | Paie conforme sans localisation éditeur, en configuration pure |

| Reprise de données (Sage/EBP/Ciel → Odoo) | CICM, Victoria, CCIFM | Extraction, nettoyage, dédoublonnage, formatage, import, validation ; pour la compta : mapping comptes/analytique + contrôle de balance | Référentiels souvent inclus, historiques chiffrés à part ; découpage en 4 lots type (cf. Annexe E.11) |

| Connecteur technique & publication Marketplace | GlobalPOS | Développement module natif OWL/Python + publication Odoo Store | Nécessite Odoo.sh/On-Premise (SaaS exclu pour du custom) |

| Gestion des incidents terrain / alertes multi-sites (Site Alert) | AXIAN Energy | Remplacement Forms/Power Automate/Lists : déclaration mobile, ségrégation par profil/site/pays, criticité paramétrable, notifications & rappels, dashboards par profil, sur instance Odoo existante (NEA/PJM) | Capitaliser sur l'instance déjà déployée (licences mutualisées, cloisonnement éprouvé) ; échéancier 30 % acompte / 40 % fin de réalisation / 20 % PV de recette / 10 % après MEP |

| ERP de reprise d'activité / continuité (distribution de pièces, VMI, import UEMOA, FEC) | IBS Burkina (ATOS) | Reprise des activités Sandvik au Burkina : ventes, achats, stocks, VMI, compta SYSCOHADA, reporting ; périmètre recentré sur l'objectif client (MNT/RH/paie exclus, paie externalisée comptabilisée) | 2 lots (socle de continuité 10 sem. + contrôle & pilotage 14 sem.) avec mises en service progressives S6/S10/S17/S24 ; connecteur facture électronique certifiée DGI (SECeF/MCF) ; serveur local magasin pour le hors-ligne ; matrice §31 ligne à ligne |

---

## Annexe E — Bibliothèque de contenus réutilisables (extraite des offres déjà émises)

> Alimentée le 21/09/2026 à partir de 7 offres réelles (CICM, Stephaina, EPIC, Sakamanga, HERi, Victoria, GlobalPOS). Sert de base de calibrage — **jamais à copier tel quel** : toujours ajuster au périmètre, à la volumétrie et au client réels.

### E.1 — Gabarit standard d'un lot (brique récurrente)

Quasi tous les lots observés suivent la même structure — s'en servir comme trame par défaut pour chiffrer un nouveau lot :

- 1 atelier kick-off / lancement

- X h d'onboarding métier (généralement 5 utilisateurs max)

- X h d'atelier pratique (généralement 5 utilisateurs max)

- Paramétrages spécifiques au client

- X h d'accompagnement post-déploiement (validité 1 à 3 mois après mise en production)

- Durée d'implémentation en semaines

### E.2 — Fourchettes de prix indicatives observées (Ar HT, hors licences/hébergement)

Ordres de grandeur réels, à recalibrer selon le périmètre — jamais un tarif fixe :

| Brique | Fourchette observée (Ar HT) | Source |

|---|---|---|

| Audit & cadrage préalable | 3 250 000 – 3 900 000 | EPIC, Stephaina, HERi |

| Comptabilité générale & analytique | 9 750 000 – 22 000 000 (selon périmètre) | CICM, Stephaina, EPIC |

| RH & Paie Malagasy | 10 000 000 – 12 750 000 | CICM, Stephaina, Sakamanga, HERi |

| Achats & Stock / Appro | 14 000 000 (pack dédié) | Victoria |

| POS / Plateau prestation | 14 950 000 | Stephaina |

| CRM / Gestion commerciale | 4 550 000 – 15 500 000 (selon périmètre) | Stephaina, Victoria |

| Portail collaborateur | 4 500 000 | HERi |

| Présence RH & biométrie (hors matériel) | 4 500 000 | EPIC |

| Formation avancée (ex. trésorerie, 2 jours) | 2 500 000 | HERi |

| Infrastructure / déploiement (création environnement) | 3 000 000 | CICM |

| Connecteur technique (dev + publication Marketplace) | 9 000 € HT | GlobalPOS |

| Intervention TMA à la carte | 95 000 Ar HT / heure | CICM |

### E.3 — Échéanciers de paiement observés (variantes à choisir selon le contexte)

| Variante | Répartition | Contexte type |

|---|---|---|

| 3 jalons classiques | 30 % commande / 50 % livraison qualification / 20 % mise en production | CICM (par module), EPIC Lot 2 |

| 4 jalons détaillés | 20 % acompte mobilisation / 15 % cadrage livré / 45 % déploiement-mise en service / 20 % recette finale | Stephaina, HERi |

| Jalons par lot successif | 40 % signature / 20 % par lot livré (×3) | Victoria (offre multi-lots) |

| Développement technique | 30 % commande / 40 % fin développement / 30 % livraison finale | GlobalPOS |

| Court / 2 temps | 50 % commande / 50 % livraison qualification | Sakamanga, EPIC Lot 3 |

| Prestation courte (audit) | 100 % à la commande | EPIC Lot 1 (audit) |

### E.4 — Garantie post-déploiement observée

Format récurrent : *« X heures d'accompagnement post-déploiement, valable Y mois après la mise en production »*.

- Petits lots (CRM, portail) : 8–16 h, validité 1–2 mois.

- Lots moyens (RH, compta) : 16–24 h, validité 2 mois.

- Lots complets multi-modules : 32–48 h, validité 1–3 mois.

- Prestations techniques (connecteur) : garantie 1 mois, correctifs bugs + hotfixes production inclus.

### E.5 — Formules TMA type (à proposer après la garantie)

**Modèle à paliers (3 formules), réutilisable tel quel :**

|---|---|---|---|---|

Paiement 100 % à la commande ; frais de déplacement/hébergement hors Tana en sus (source : EPIC).

**Modèle à la carte** : intervention facturée à l'heure (95 000 Ar HT/h observé, CICM) pour des besoins ponctuels hors accompagnement standard.

**Modèle forfait annuel + crédit d'heures** (clients offshore / techniques) : forfait annuel (ex. 4 800 € HT/an), crédit d'heures cumulable (ex. 192h), ticketing dédié + SPOC des deux côtés, plage horaire précisée (source : GlobalPOS).

### E.6 — Licences & hébergement, gabarit de simulation

Tableau type à reproduire (avec le nombre d'utilisateurs du dossier en cours) :

| Poste | Exemple observé |

|---|---|

| Licences utilisateurs (nombre) | 3 à 22 selon le client |

| Tarif licence / utilisateur / mois | ~13,6 $ (remise 1ʳᵉ année déduite) |

| Odoo.sh — dimensionnement | ~1 unité de traitement pour 3 utilisateurs backend simultanés, 50 Go stockage, 1 environnement staging |

| Total mensuel / 12 mois / 36 mois | à calculer (taux $→Ar arrondi, ex. 1 $ ≈ 4 300 Ar, à vérifier au jour du chiffrage) |

Notes pratiques à répéter systématiquement : *« Montants finalisés dès confirmation du nombre de licences »* ; *« Achat licence et hébergement auprès de l'éditeur, dans la semaine suivant le démarrage du projet »* ; toujours préciser que ces coûts sont **estimatifs, à affiner en cours de projet**.

### E.7 — Gabarit Périmètre In/Out (base Victoria)

**Inclus type** : atelier de cadrage par lot, paramétrage complet du périmètre décrit, reprise des référentiels (clients/fournisseurs/articles/plan comptable), recette fonctionnelle (UAT), formation des utilisateurs finaux, documentation, mise en production + assistance renforcée au go-live.

**Inclus type (reporting)** : TDB et KPI natifs au sens de la Règle 5.10, listés par nom.

**Hors type** : développements spécifiques non identifiés en amont, TDB/KPI nécessitant du code (recalcul, requête spécifique) ou Odoo Studio (cf. Règle 5.10), reprise de l'historique (transactions), intégrations systèmes tiers (API/EDI/middleware), maintenance après le projet (hors garantie), licences et hébergement (facturés par Odoo), matériel/réseau/postes de travail.

### E.8 — Gabarit Gouvernance (base Victoria)

**Côté EdooIt** : Chef de projet (interlocuteur unique — cadrage, pilotage, arbitrages de périmètre) ; Consultant fonctionnel Odoo (paramétrage, recette, formation) ; Développeur (mobilisé ponctuellement — reprise référentiels, ajustements techniques).

**Côté client attendu** : Sponsor projet (arbitrages et validation des jalons) ; Chef de projet / interlocuteur unique (pilotage, décisions) ; Key users (recette, puis relais de formation interne).

**Rituels** : point hebdomadaire (1h max, avancement et blocages) ; comité de pilotage (à chaque fin de lot, avant mise en production) ; recette formalisée (validation écrite avant chaque go-live).

### E.9 — Gabarit Engagements réciproques (base Victoria)

**Ce que nous engageons** : un chef de projet unique du cadrage à la mise en production ; un environnement de test disponible dès la semaine 1 ; un compte-rendu écrit après chaque atelier ; une formation sur données réelles, pas un jeu de démonstration ; la documentation remise avant chaque mise en production.

**Ce que nous demandons** : les référents désignés avant démarrage, avec du temps réellement dégagé ; les fichiers de référentiels fournis au format convenu en semaine 1 ; la validation des livrables sous 5 jours ouvrés ; les accès réseau et comptes utilisateurs ouverts avant paramétrage.

Clause de décalage : *« Tout retard sur ces prérequis se répercute directement sur le planning — le délai court à partir de la mise à disposition effective des référents et des données. »*

### E.10 — Références clients citables

Secteurs déjà couverts, citables sans détail confidentiel (vérifier l'accord du client avant citation nominative dans une nouvelle offre) : santé publique / recherche (CICM), beauté & bien-être multi-sites (Stephaina), hôtellerie & restauration (Sakamanga), énergie solaire / distribution (HERi), hygiène professionnelle multi-pays Réunion/Mayotte/Madagascar (Victoria), paiement & encaissement retail (GlobalPOS), industrie/distribution (EPIC). Références nommées déjà citées en offre : AC2V Services (Odoo Entreprise), MAKINA O.I, NIC.MG.

### E.11 — Gabarit de chiffrage : reprise de données comptables (base CCIFM, Ciel → Odoo)

> Chiffrage type d'une reprise **one-shot** de comptabilité vers Odoo (ex. Ciel Compta, sur plusieurs exercices). Exemple observé sur un cas à 3 exercices — **les heures ne sont pas à recopier telles quelles**, elles dépendent du volume, du nombre d'exercices, de la complexité du lettrage et du nombre de journaux à mapper.

**Résumé des hypothèses à documenter dans le chiffrage** (posées à partir d'un extrait test analysé, pas encore validées sur toute la période) :

- Devise unique de traitement à confirmer (ou logique de conversion à chiffrer en plus si multi-devises sur les exercices non testés).

- Clé de rapprochement (n° de compte + code lettrage) validée sur l'extrait testé (ex. 855 groupes, tous équilibrés) — **à revalider sur les exercices non encore testés**.

- Volume de codes analytiques supposé comparable sur toute la période, à confirmer.

- Correspondance des journaux source → Odoo (ex. 11 journaux) à établir avant chiffrage définitif.

- Mapping plan comptable et analytique traité comme un **simple fichier de configuration** (pas de module Odoo réutilisable), l'outil étant jetable après la reprise.

- Confirmation que les exercices/périodes à reprendre ne sont **pas verrouillés** dans Odoo (un exercice clôturé peut bloquer la création d'écritures rétroactives).

**Charges prévues (exemple observé, 3 exercices) :**

| Lot | Tâche | Estimation (h) |

|---|---|---|

| **A — Cadrage rapide** | Récupération des extraits complets + test du prototype de lettrage | 4 |

| A | Mapping plan comptable source → Odoo | 5 |

| A | Mapping codes analytiques (validé avec le client) | 3 |

| *Sous-total A* | | *12* |

| **B — Transformation & push (script one-shot)** | Transformation combinée (comptes + lettrage + analytique) | 8 |

| B | Script de push Odoo (API/XML-RPC : écritures + réconciliation) | 10 |

| B | Tests sur échantillon avant le run complet | 2 |

| *Sous-total B* | | *20* |

| **C — Test global et recette** | Import complet sur environnement de test | 3 |

| C | Contrôle croisé automatique des balances (source vs Odoo, écart attendu = 0) | 2 |

| C | Corrections des anomalies détectées | 3 |

| C | Recette écrite du client sur les soldes clés | 2 |

| *Sous-total C* | | *10* |

| **D — Bascule finale** | Import définitif en production (avec sauvegarde préalable) | 3 |

| D | Vérification finale des soldes en production | 2 |

| D | Note de clôture (traçabilité, pas un guide utilisateur) | 1 |

| *Sous-total D* | | *6* |

| **Total avant marge** | | **48** |

| **Marge de sécurité (~10 %)** | | **4,8** |

| **Total avec marge** | | **52,8** |

**Risques à nommer explicitement dans l'offre** : écritures en devise étrangère non couvertes par l'estimation si elles apparaissent sur des exercices non testés ; exercice verrouillé nécessitant une procédure de déverrouillage à valider avec l'administrateur Odoo du client ; volume réel de cas particuliers de lettrage (lettrages partiels, écritures manuelles atypiques) inconnu avant test ; droits insuffisants de l'utilisateur API côté client bloquant le démarrage du Lot B.

**Principe — outil jetable.** Solution volontairement minimale pour une reprise ponctuelle : pas de mécanisme de surveillance ni de robustesse pour un usage récurrent, pas de guide utilisateur (l'outil n'est plus utilisé après la bascule) — cf. Principe 9 (dimensionnement au juste besoin).

---

## Annexe D — Gouvernance du référentiel (mise à jour du document lui-même)

**Règle G.1 — Mise à jour en fin d'avant-vente, en deux volets distincts.** À la fin de chaque dossier traité :

1. **Catalogue de modules & solutions (Annexe C)** — enrichi directement, sans validation préalable (simple journal de ce qui a été proposé).

2. **Règles elles-mêmes (sections 0 à 9 et annexes A/B)** — mises à jour si une nouvelle bonne pratique émerge, **uniquement après validation explicite de Nandrianina** ; ne jamais modifier une règle sans la lui soumettre d'abord.

**Règle G.2 — Source unique, pas de skill.** Depuis le 21/09/2026, ce fichier est l'unique source de règles utilisée par Claude pour les avant-ventes — aucune skill Claude n'est utilisée en complément ou en miroir. Toute mise à jour se fait directement ici.

---

*Fin du référentiel. Voir Annexe D pour la gouvernance des mises à jour — dernière évolution des règles : 07/10/2026 (statut affiché : « Partner Odoo », sans « Gold » ; Règle 2.2 : 10 slides max sans redondance ; Règle 1.9 : questions client 20 max + call, seuil bloquant à 20 % d'inconnus structurants ; Règle 5.10 : règle du natif pour les tableaux de bord) ; précédentes : 06/10/2026 (Règle 2.1 : corps principal resserré jusqu'au prix, détails en annexes référencées) ; 21/09/2026 (dimensionnement au juste besoin, Brief/Checklist référencés directement sans copie systématique, marque unique EdooIt, alternative d'hébergement VPS + infogérance, catalogue de solutions, gabarit de reprise de données comptables, gouvernance des mises à jour).*

Join this Course

Responsible	RAVELOSON Nandrianina
Last Update	10/08/2026
Members	2

Course
Reviews

No lessons are available yet.