Gérer la prime ADVENIR dans Odoo : la méthode conforme à la TVA

Tout a commencé par un appel d'un prospect. Il installe des bornes de recharge pour véhicules électriques, il vient de découvrir Odoo, et il a un problème simple en apparence : ses devis ne tombent pas juste quand il déduit la prime ADVENIR.

Le sujet m'a intéressé. Pas seulement parce que c'était une opportunité commerciale, mais parce que je venais de configurer Claude Code dans l'interface Odoo.sh et j'attendais un cas concret pour le tester sérieusement. Spoiler : trois jours plus tard, le module stellarius_advenir_subsidy tournait en production chez le client. Voici comment.

💌 Vous êtes intéressé par ce module ? Je vous propose de me contacter directement pour obtenir le code source et discuter de votre cas d'usage. Les coordonnées sont en bas de l'article.

Pourquoi Odoo standard ne sait pas gérer la prime ADVENIR

Si vous travaillez dans l'IRVE (Infrastructure de Recharge pour Véhicules Électriques), vous connaissez la prime ADVENIR. C'est un dispositif financé par les Certificats d'Économie d'Énergie (CEE) qui permet à l'installateur de proposer une remise immédiate au client final, puis de se faire rembourser par l'organisme ADVENIR.

Concrètement, voilà à quoi devrait ressembler une facture Odoo pour une borne à 3 000 € HT avec prime de 1 000 € :

Désignation	HT	TVA 20%	TTC
Borne + installation	3 000,00 €	600,00 €	3 600,00 €
Prime ADVENIR	—	—	-1 000,00 €
Net à payer			2 600,00 €

Le client paie 2 600 €. L'installateur récupère 1 000 € auprès d'ADVENIR. L'État collecte la TVA sur 3 000 € de chiffre d'affaires. Tout le monde est content.

Sauf qu'avec Odoo en standard, ça ne marche pas. Si vous créez un produit "Prime ADVENIR" à -1 000 € et que vous l'ajoutez à un devis avec TVA 20%, Odoo applique mécaniquement la TVA sur cette ligne. Résultat : -1 200 € de déduction au lieu de -1 000 €.

Si vous saisissez -833,33 € HT pour obtenir -1 000 € TTC, vous intégrez la prime dans la base TVA, ce qui contredit directement la doctrine fiscale.

La règle fiscale : la prime ADVENIR n'est pas soumise à TVA

Premier réflexe : j'ai proposé au prospect une solution Odoo standard avec un produit à prix HT calculé pour retomber sur les bons totaux. Ça marche techniquement, c'est rapide à mettre en place, pas de développement.

Mon associé chez MCG m'a stoppé net : "Les subventions ne sont pas soumises à TVA." Et il avait raison.

J'ai vérifié à la source. La FAQ officielle d'Avere-France (qui pilote ADVENIR) est limpide :

« De par les règles applicables aux programmes CEE, la prime Advenir n'est pas soumise à la TVA. La TVA d'une opération candidate à la prime Advenir devra donc être calculée sur la base de l'ensemble des coûts HT avant déduction de la prime. (…) la prime Advenir devra être déduite du montant TTC de l'opération. »

Donc trois règles à respecter pour toute facturation ADVENIR sous Odoo, dans cet ordre précis :

1. Calculer la TVA sur le HT brut, sans tenir compte de la prime
2. Déduire la prime du TTC, après application de la TVA
3. Ne jamais faire entrer la prime dans la base TVA

Aucune des solutions que je connaissais sous Odoo ne permettait ça nativement. Pas de produit à TVA "neutre", pas de mécanisme de remise post-TVA, rien. Il fallait coder un module Odoo dédié.

Pourquoi développer un module Odoo dédié plutôt qu'un contournement

Pour situer : je développe en Python et en C# depuis 25 ans, j'ai déjà écrit des dizaines de modules Odoo. Je n'avais aucun besoin d'une IA pour coder ce module. J'aurais pu le faire en 2 jours sans assistance.

Mais Stellarius est partenaire Odoo depuis janvier 2024, et je suis seul à porter le développement de la boîte. Mon temps est ma ressource la plus rare. Si Claude Code peut me faire gagner 30% du temps sur ce genre de module, ça change beaucoup de choses pour mon modèle économique.

Il y avait aussi un autre angle : je voulais voir ce que ça donnait avec l'intégration native Odoo.sh, qui était nouvelle pour moi. Si ça marchait bien, je pourrais l'utiliser pour mes prochains chantiers chez les clients.

Environnement de développement : Odoo 19 Enterprise sur Odoo.sh

Mon prospect tournait déjà sur Odoo 19 Enterprise hébergé sur Odoo.sh. Le projet avait les trois étages classiques : Production, Staging, Development. Les modules Sales et Accounting étaient déjà installés.

J'ai créé une branche dédiée nommée feat-advenir-subsidy en stage Development. Sur Odoo.sh, chaque branche dev est un environnement isolé avec sa propre base de démonstration. Je pouvais casser autant que je voulais sans toucher la prod.

Pour Claude Code, l'onglet AI d'Odoo.sh donne directement accès à Claude Code v2.1.90 (au moment où j'écris cet article). Premier piège : l'authentification utilise le compte Claude actif dans la session Chrome courante. J'ai perdu vingt minutes à comprendre pourquoi ça me connectait au mauvais compte. La solution est triviale : se déconnecter de claude.ai dans Chrome, ou utiliser une fenêtre privée. Mais ce n'est documenté nulle part.

Le brief permanent : le fichier CLAUDE.md

C'est là que Claude Code devient vraiment intéressant. Il lit automatiquement un fichier CLAUDE.md à la racine de chaque projet et l'utilise comme contexte permanent.

J'ai pris le temps d'y mettre tout ce qui comptait pour ce module :

markdown

# Contexte du module stellarius_advenir_subsidy

## Règle fiscale fondamentale
La prime ADVENIR relève des CEE et n'est pas soumise à TVA.
- TVA calculée sur le HT brut du devis
- Prime déduite du TOTAL TTC uniquement
- HT et TVA non impactés par la prime

## Exemple chiffré
Borne 3000€ HT + TVA 20% = 3600€ TTC
Prime ADVENIR : -1000€ TTC (sans TVA)
Net à payer client : 2600€

## Architecture cible
Modèles à étendre :
- product.template : flag is_post_tax_deduction + compte comptable
- sale.order.line : neutraliser HT et TVA si CEE
- sale.order : recalcul amount_total
- account.move.line : idem
- account.move : idem

## Conventions de code
- Licence LGPL-3, auteur Stellarius
- Commentaires en français
- Tests obligatoires
- Pas de dépendance externe hors sale_management + account

Sans ce fichier, Claude Code va deviner. Avec ce fichier, il sait exactement ce qu'il a à faire. La différence en qualité de code est énorme.

La méthode de développement : prompts incrémentaux

J'ai vite compris qu'il ne faut surtout pas dire "code-moi tout le module". C'est la meilleure façon d'avoir 600 lignes de Python à débugger en aveugle.

L'approche qui marche : un prompt = un fichier = un commit. Voici l'ordre que j'ai suivi pour le développement du module Odoo ADVENIR :

Prompt 1 : étendre product.template avec le champ is_post_tax_deduction et la contrainte qui interdit les taxes sur ces produits.

Prompt 2 : surcharger _compute_amount sur sale.order.line pour neutraliser le HT et la TVA des lignes CEE. Avant de coder, je lui ai demandé de lire le fichier source d'Odoo concerné. Sans cette consigne explicite, il code de mémoire et invente des signatures.

Prompt 3 : recalculer les totaux globaux sur sale.order avec un nouveau champ amount_post_tax_deduction.

Prompts 4 et 5 : transposer la logique sur account.move.line et account.move.

Prompt 6 : créer les vues XML pour exposer les nouveaux champs.

Prompt 7 : étendre les templates QWeb (sale.document_tax_totals et account.document_tax_totals) pour afficher la déduction sur les PDF.

Prompt 8 : écrire les tests automatisés.

Entre chaque prompt, je relisais le code proposé avant de valider l'écriture, puis je commitais. Un commit par feature, message clair, message en anglais (convention OCA). En cas de plantage à l'étape suivante, je pouvais revert sans tout perdre.

Là où Claude Code excelle (et là où il déçoit)

Ce qui marche très bien.

Quand on lui demande de lire le code source d'Odoo avant de coder, il s'en sort remarquablement. Il a trouvé tout seul la bonne signature de _compute_amount en Odoo 19, qui avait légèrement changé par rapport à Odoo 17. Il a aussi détecté que le template document_tax_totals est un sous-template appelé par report_invoice_document, et il a su étendre le bon niveau.

Les tests automatisés qu'il a écrits étaient bons du premier coup. Il a pensé tout seul à tester le cas négatif (essayer d'ajouter une TVA sur un produit CEE → ValidationError). Ce genre de réflexe qualité, c'est ce qui distingue un bon générateur de code d'un autocomplete amélioré.

Ce qui m'a fait perdre du temps.

Sur le calcul de amount_total au niveau account.move, sa première version cassait le lettrage des paiements parce qu'il modifiait amount_residual après coup au lieu d'intervenir dans le flow standard. J'ai dû le reprendre. À sa décharge, c'est un piège classique d'Odoo et même un dev expérimenté peut tomber dedans.

Le template QWeb a aussi nécessité trois aller-retours. Il avait tendance à dupliquer des blocs au lieu d'utiliser position="inside" proprement. Là encore, rien d'insurmontable, mais ça demande de relire chaque XPath.

Le workflow Git sur Odoo.sh : un piège qui m'a coûté une heure

J'ai voulu faire les choses bien et créer une branche staging dédiée nommée staging-advenir avant de pousser en production. Logique classique : checkout main, créer la branche, merger ma branche feature, push.

Sauf que sur Odoo.sh, les shells des builds (Development, Staging, Production) ne peuvent pas pusher vers GitHub. Pas de clé SSH, pas d'autorisation. Ils sont consommateurs de code, pas producteurs.

L'erreur que j'ai eue :

Warning: Identity file /home/odoo/containers/.../keys/git_github.com_...git
not accessible: No such file or directory.

Si vous voyez ça, ne cherchez pas plus loin : vous êtes au mauvais endroit. Trois solutions possibles :

1. Utiliser l'interface Odoo.sh (drag & drop entre les sections Development → Staging → Production). C'est ce que j'ai fait au final.
2. Utiliser l'éditeur web (onglet EDITOR) qui peut commiter et pusher
3. Travailler en local sur sa machine avec un clone du repo

Pour ce module, le drag & drop était parfait. Tu glisses ta branche dev sur la section Staging, Odoo.sh duplique la base de prod et lance un build avec ton code. Tu testes. Si tout va bien, tu glisses la branche staging sur la branche main, et la prod est mise à jour automatiquement.

C'est élégant. Une fois qu'on a compris la logique.

Mise en production sur Odoo.sh : la procédure pas à pas

Avant de cliquer sur le merge production, j'ai pris deux précautions.

Premièrement, j'ai déclenché un backup manuel de la prod depuis l'interface Odoo.sh. Les backups quotidiens existent, mais je voulais un point de restauration daté précisément avant mon merge.

Deuxièmement, j'ai prévenu mon prospect par mail : "Mise en prod du module ADVENIR dans 15 minutes, interruption de service possible pendant 5 minutes." Le respect élémentaire du client.

Le merge a déclenché un build de prod en 7 minutes. L'instance est restée accessible pendant la quasi-totalité du build (Odoo.sh gère ça plutôt bien) et le module est apparu dans la liste des Apps. Mon prospect l'a installé lui-même, créé son premier devis avec prime ADVENIR, et m'a renvoyé un message une heure plus tard : "C'est exactement ce qu'il me fallait."

💡 Si vous avez un client installateur IRVE qui rencontre exactement ce cas, parlons-en directement — je peux vous transmettre le code du module pour gagner du temps.

Quel compte comptable utiliser pour la prime ADVENIR ?

Un point qui m'a pris du temps : quel compte comptable pour la déduction CEE ?

J'ai longtemps hésité entre trois options :

• 758 "Produits divers de gestion courante" : simple, mais comptablement incorrect (la prime n'est pas un produit divers)
• 709 "Rabais, remises et ristournes accordés" : bonne logique, mais mélange avec les vraies remises commerciales
• Sous-compte dédié 7097 ou 7091 "Primes ADVENIR rétrocédées" : la solution propre

J'ai opté pour la troisième dans le module, mais sans la coder en dur. Le compte est paramétrable par produit, ce qui permet à chaque comptable d'adapter à son plan de comptes. C'est ce détail qui distingue un module amateur d'un module pro : ne jamais imposer une règle comptable.

L'écriture finale d'une facture ADVENIR ressemble à ça :

411 Client                    Débit  2 600,00 €
467 Tiers ADVENIR             Débit  1 000,00 €
    707 Ventes                Crédit          3 000,00 €
    44571 TVA collectée       Crédit            600,00 €

La TVA est calculée sur 3 000 €. Le client paie 2 600 €. L'installateur attend 1 000 € de l'organisme ADVENIR. Tout est carré du point de vue de la doctrine fiscale CEE.

Bilan : 3 jours pour un module Odoo ADVENIR en production

Si je devais refaire la même chose sans Claude Code, j'estime à 4-5 jours de boulot. Avec Claude Code, j'en ai eu pour environ 2,5 jours de développement réel, plus la phase de tests et de recette avec le client.

Le gain de temps est réel mais pas magique. Claude Code n'a pas écrit le module à ma place. Il a accéléré la phase de codage et m'a évité quelques recherches dans le code source d'Odoo. Le travail de conception, le choix architectural, la validation fiscale, la décision sur les comptes comptables, tout ça reste 100% humain. Et c'est très bien comme ça.

Trois enseignements que je retiens :

Premier enseignement : un bon CLAUDE.md vaut mieux que 50 prompts détaillés. Investissez 30 minutes pour le rédiger sérieusement avant de commencer.

Deuxième enseignement : prompts incrémentaux, commits fréquents, relecture systématique. C'est exactement la méthode d'un dev junior bien encadré. Claude Code est un dev junior très rapide.

Troisième enseignement : Odoo.sh + Claude Code, c'est un combo redoutable pour de l'intégration ERP, mais il faut connaître les pièges (authentification Chrome, workflow Git, shells consommateurs et pas producteurs). Une fois ces pièges connus, c'est très productif.

Vous voulez le code source du module ?

Le module stellarius_advenir_subsidy est opérationnel et testé en conditions réelles sur Odoo 19 Enterprise. Si vous êtes dans l'un des cas suivants, contactez-moi :

• Vous êtes installateur IRVE et vous galérez avec Odoo pour gérer la prime ADVENIR
• Vous êtes intégrateur Odoo et vous avez un client dans ce secteur qui vous pose la question
• Vous gérez d'autres dispositifs CEE dont la logique fiscale est similaire (MaPrimeRénov', primes énergie, etc.) et vous voulez voir comment j'ai résolu le problème
• Vous êtes développeur Odoo et vous voulez simplement voir le code pour vous inspirer

Je transmets le code source du module en LGPL-3 sur simple demande, avec un échange préalable pour comprendre votre contexte. Cet échange est gratuit, et selon la complexité de votre cas, on peut éventuellement déboucher sur une mission d'adaptation ou d'intégration chez vous.

Pour me contacter :

• 📧 Par mail via le formulaire de contact sur www.stellarius.fr
• 💼 Sur LinkedIn : Roland Géromegnace

Précisez "Module ADVENIR" dans votre message pour qu'il arrive directement dans la bonne file.

Questions fréquentes sur la gestion de la prime ADVENIR dans Odoo

La prime ADVENIR est-elle soumise à TVA ?

Non. La prime ADVENIR relève du dispositif des Certificats d'Économie d'Énergie (CEE) et n'est pas soumise à la TVA. La TVA doit être calculée sur le HT brut du devis, et la prime est déduite ensuite du total TTC. Cette règle est explicitement confirmée par la FAQ officielle d'Avere-France.

Sur quel compte comptable imputer la prime ADVENIR ?

Le compte recommandé est un sous-compte dédié type 7097 ou 7091 "Primes ADVENIR rétrocédées clients". Cela permet d'isoler ces opérations des autres remises commerciales pour le suivi et la déclaration fiscale. Les comptes 758 (produits divers) ou 709 (RRR accordés) sont possibles mais moins propres comptablement.

Faut-il développer un module Odoo spécifique pour gérer la prime ADVENIR ?

Oui. Odoo en standard applique systématiquement la TVA sur toutes les lignes d'un devis. Un module dédié est nécessaire pour neutraliser le calcul de TVA sur la ligne de prime ADVENIR sans pour autant modifier la base imposable du reste du devis. Sans module, vous obtenez soit une déduction de -1200 € au lieu de -1000 €, soit une intégration incorrecte de la prime dans la base TVA.

Quelle version d'Odoo supporte ce module ?

Le module développé par Stellarius est compatible avec Odoo 19 Enterprise. Une adaptation pour Odoo 18 Enterprise, Odoo 17 ou Odoo Community est possible sur demande, car la logique reste la même.

Combien de temps faut-il pour développer un tel module ?

Avec une bonne maîtrise d'Odoo et de Python, comptez 2,5 à 5 jours selon que vous utilisez ou non un assistant IA comme Claude Code. La partie la plus longue n'est pas le code mais la validation fiscale et le paramétrage comptable, qui doivent être validés par l'expert-comptable du client.

Pour aller plus loin

Quelques liens utiles pour creuser le sujet :

• Programme ADVENIR officiel : advenir.mobi
• Documentation Odoo 19 : odoo.com/documentation/19.0
• Claude Code : code.claude.com
• Doctrine fiscale française (BOFiP) : bofip.impots.gouv.fr

Et si vous voulez creuser la même méthode pour d'autres modules Odoo ou échanger sur l'intégration ERP en général, n'hésitez pas à nous contacter directement.

Contactez-nous