Clés NFR d'Odoo : ce que c'est, qui les demande et comment les obtenir

Si vous êtes arrivé ici en cherchant « NFR » et que vous vouliez dire exigences non fonctionnelles (performance, disponibilité, tolérance aux pannes), cette page n'est pas pour vous. Ici, NFR signifie Not For Resale : la licence qu'un éditeur de logiciels accorde à ses partenaires pour monter des démonstrations et des environnements internes sans les payer. Et il faut savoir une chose : Odoo n'appelle rien NFR. Le mot n'apparaît pas une seule fois dans l'Accord de Partenaires d'Odoo (version 11, du 19 mai 2023). Ce que vous cherchez existe, mais sous un autre nom : il n'y a pas de clé, il y a une clause de la licence Enterprise qui s'active à la signature de l'accord de partenaire, et un code qui ouvre un projet d'essai sur Odoo.sh.

Nous l'écrivons de l'intérieur : FLEXIBLES Y ACCESORIOS GOBE S.L. (la société derrière FlexigoTech) est entrée dans le programme de partenaires d'Odoo le 8 septembre 2026, au niveau Learning Partner. Nous ne publions pas de capture du panneau, car il contient des identifiants et des montants ; nous le décrivons champ par champ plus bas.

Sceau de Learning Partner. Le droit d'utiliser la marque et le logo d'Odoo figure comme Yes dans les quatre niveaux du tableau de la section 4.2.

Pourquoi l'acronyme vous renvoie des résultats inutiles

NFR a deux significations sans rapport. En ingénierie logicielle, c'est non-functional requirement, un attribut de qualité du système. Dans le canal de distribution, c'est not for resale, une licence gratuite d'usage interne pour les distributeurs. La seconde a très peu de littérature en espagnol et aucune sur Odoo, si bien que la recherche vous renvoie des glossaires d'exigences et des programmes de canal sans rapport.

Ce qu'Odoo vous donne à la place d'une clé NFR

Trois choses distinctes, avec trois noms propres et trois endroits où les demander. Les mélanger est à l'origine de presque toute la confusion.

1. Le droit d'usage d'Enterprise. Ce n'est pas une clé, c'est une clause. La licence Odoo Enterprise Edition v1.0 dit que « avec un Accord de Partenaires valide avec Odoo S.A., les permissions ci-dessus sont également accordées, à condition que l'usage soit limité à un environnement de test ou de développement ». Cette phrase est toute votre « licence NFR ».
2. Le code de partenaire. Celui-ci est bien une chaîne que l'on saisit dans un formulaire et qui ouvre un projet d'essai sur Odoo.sh. Le droit découle de la section 3.1 de l'accord (« Odoo accorde au partenaire un accès gratuit à la plateforme Odoo.sh à des fins de test et de développement ») ; le mécanisme, de la documentation d'Odoo.sh, qui indique que les partenaires peuvent utiliser leur code de partenaire pour lancer un essai. De première main : dans notre panneau de Learning Partner, le code qui apparaît étiqueté est celui de prolongation d'essai ; si vous ne voyez pas celui de partenaire, demandez-le à votre gestionnaire de compte.
3. Le code de prolongation de l'essai d'Enterprise. Un troisième code qui n'est pas pour vous : il prolonge la période d'essai d'un client potentiel. Le tableau des avantages de la section 4.2 l'indique comme disponible dans les quatre niveaux.

En plus, il y a l'accès en lecture au dépôt du code source d'Odoo Enterprise sur GitHub, qui vous permet de compiler et de tester des modules contre Enterprise sur votre machine.

À quoi ils servent vraiment et à quoi ils ne servent pas

Ils servent à la démonstration commerciale, à la formation interne et au développement et aux tests de vos modules, y compris tester la même base contre plusieurs versions majeures avant une migration. Ils ne servent pas à la production d'un client, et l'accord est inhabituellement tranchant : la section 3.2 dit que le partenaire s'engage à ne pas proposer de services sur Odoo Enterprise Edition à des clients non couverts par un abonnement Enterprise, pas même pendant la phase de mise en place. Il n'y a pas de fenêtre de tolérance pendant que vous configurez.

Ils ne servent pas non plus à redistribuer quoi que ce soit : la même section oblige à garder le code source d'Enterprise confidentiel au sein de l'équipe et interdit de le redistribuer sans autorisation écrite. Ce que vous pouvez faire, c'est développer des modules par-dessus Enterprise et les distribuer sous toute licence compatible : la licence d'Enterprise l'autorise et cite LGPL, MIT ou des licences propriétaires similaires.

Qui peut les demander et à quel moment de l'inscription

Il n'y a rien avant la signature : la clause de la licence parle d'un « Accord de Partenaires valide », et sans accord il n'y a pas de clause. La section 5 dit que le montant de la cotisation est précisé par écrit au moment de la signature (ce n'est pas un chiffre publié), qu'il se paie à la réception de la facture annuelle et qu'il n'est pas remboursable. La section 2 fixe la durée à un an à compter de la signature, avec reconduction automatique sauf préavis écrit d'une des parties 30 jours avant. Le programme compte deux types de partenariat et quatre niveaux, et le niveau dépend de trois chiffres.

Le détail qui compte ici : l'accès à Odoo.sh pour les tests et le développement, le code de prolongation d'essai et l'accès au code source figurent comme Yes dans les quatre niveaux. Vous les avez dès le premier jour comme Learning Partner. Ce que l'on n'obtient pas, c'est la visibilité dans la liste publique des partenaires d'odoo.com et la commission de 50 % sur Odoo.sh, qui reste à 10 % en Learning : et qui, à tout niveau, est plafonnée : la note de bas de page de la section 4.2 la limite à 150 € (ou 180 $) par mois et par abonnement, 1 440 € (ou 1 728 $) par an. Une observation de première main : la ligne qui regroupe le gestionnaire de compte dédié et le panneau de partenaire est marquée No en Learning, et pourtant, lors de notre inscription de septembre 2026, le panneau était bien là et on nous a attribué une gestionnaire de compte avec téléphone et e-mail directs. La section 4.4 elle-même dit en outre que le partenaire aura accès au coaching commercial de son gestionnaire de compte, sans distinction de niveau. Le contrat est le plancher, pas le plafond.

La démarche, pas à pas

1. Signez l'accord et payez la cotisation annuelle. Elle se règle à la réception de la facture d'Odoo et n'est pas remboursable. Sans accord signé, il n'y a rien de ce qui précède.
2. Accédez au panneau de partenaire, sur odoo.com/my/partner. Vous y trouvez le niveau actuel et l'échelle jusqu'à Official ; le lien de parrainage, qui contient l'identifiant numérique du partenaire dans le paramètre de campagne ; le code de prolongation d'essai ; l'accès en lecture au dépôt d'Enterprise sur GitHub pour l'utilisateur que vous déclarez ; le téléchargement des sources et des installateurs ; les ressources de marque ; l'état de la fiche d'entreprise, publiée ou non ; et le compteur de commissions des douze derniers mois.
3. Ouvrez le projet de démonstration sur Odoo.sh. Cliquez sur Deploy your platform, autorisez avec un compte GitHub et, dans le champ Subscription Code (la documentation précise qu'on l'appelle aussi subscription referral, contract number ou activation code), saisissez le code de partenaire.
4. Choisissez la version majeure et la région. Odoo.sh n'admet pas les versions intermédiaires qu'exécute Odoo Online. Si vous comptez commencer sur Odoo Online et migrer ensuite, la documentation recommande de créer la base depuis odoo.com/start-lts pour qu'elle naisse dans une version compatible.
5. Quand le client dit oui, changez de code. La documentation est explicite : si le client poursuit, il doit souscrire un plan Odoo Enterprise incluant l'hébergement sur Odoo.sh et utiliser son propre code d'abonnement. Votre code de partenaire sort de l'équation.

Les limites qui surprennent

Aucune n'est secrète : toutes figurent dans la documentation officielle. Le problème, c'est qu'elles sont réparties sur cinq pages et que vous les découvrez une à une, toujours au pire moment.

• 1 Go et deux branches de staging. C'est le plafond des builds d'essai créés avec un code de partenaire. Les dumps que vous importez ne peuvent pas non plus dépasser 1 Go.
• 30 jours, et la production cesse d'être de la production. Dans les projets d'essai, la branche de production et toutes celles de staging repassent automatiquement à l'étape de développement au bout de 30 jours. C'est la véritable date d'expiration de votre démo.
• Les bases de staging se suppriment toutes seules au bout d'un mois et il faut reconstruire la branche pour la réutiliser.
• Une démo en staging n'envoie pas d'e-mails. La neutralisation désactive les actions planifiées et le courrier sortant (intercepté par un mail catcher) et coupe les services IAP, les passerelles de paiement et les modes d'expédition. La base neutralisée perd en outre la synchronisation bancaire et la visibilité pour les moteurs de recherche, et affiche un bandeau rouge en haut pour que cela se voie.
• Le changement de code est une porte à sens unique. Vous pouvez changer le code d'activation du projet, mais pas pour un code déjà attribué à un autre projet ni pour un code d'essai : repasser de payant à essai n'est pas autorisé.
• Le niveau est révisé chaque trimestre et ajusté au plus haut dont vous remplissez les trois exigences. Ce sont les nouveaux utilisateurs nets des douze derniers mois qui comptent : les renouvellements ne comptent pas pour le niveau, même s'ils génèrent une commission.
• Si l'accord prend fin, tout prend fin. La section 6.1 dit qu'à l'expiration ou à la résiliation, le partenaire ne peut plus utiliser Odoo Enterprise ni pour le développement, ni pour les tests, ni pour la production, et doit cesser d'utiliser la marque. L'expiration de votre « licence NFR » est la date de votre accord, pas celle de votre projet.

Les erreurs qui coûtent cher

• Monter la production d'un client sur votre projet d'essai. Cela enfreint la section 3.2, c'est irréversible puisqu'on ne peut pas repasser de payant à essai, et au bout de 30 jours la branche de production se dégrade toute seule. Le tout sous les yeux du client.
• Oublier le renouvellement. L'accord se renouvelle tout seul pour un an de plus si personne ne prévient par écrit 30 jours avant. Si vous voulez renouveler, aucun problème ; si vous voulez partir, l'oubli vous coûte une annuité non remboursable.
• Promettre dans une démo ce que la neutralisation coupe : e-mails, paiements réels, étiquettes de transporteur, actions planifiées. Montrez-le dans un environnement de développement avec des données de démonstration, ou prévenez avant.
• Publier du code d'Enterprise dans un dépôt public. C'est le manquement le plus discret et le plus difficile à réparer, car ce qui est public a déjà été copié.

Et si vous n'êtes pas encore partenaire ?

Deux solutions honnêtes tant que vous n'avez pas signé. Les bases de démonstration partagées d'Odoo ne demandent pas d'inscription, mais selon la documentation chacune n'est disponible que quelques heures : elles servent à montrer un écran, pas à préparer une démo sur mesure. Et Odoo Community est un logiciel libre sous LGPLv3 : si ce que vous avez à démontrer vit dans un module à vous et non dans une app d'Enterprise, c'est un environnement valable et sans expiration. Odoo Online ne l'est pas : il n'admet pas de modules personnalisés ni de l'App Store, et les duplicatas expirent au bout de 15 jours avec un maximum de cinq par base.

Nous testons chaque module sur de vrais builds d'Odoo.sh dans les versions 19, 18 et 17 avant de toucher à l'App Store : l'environnement de partenaire est exactement l'endroit où se fait ce travail. Nous l'expliquons dans ingénierie Odoo pour cabinets de conseil et dans connecteur Odoo pour votre logiciel.

Pour aller plus loin

Si la décision que vous avez devant vous est autre (quelle édition il vous faut vraiment), nous l'avons comparée dans Community ou Enterprise. Et si ce qui vous freine est de ne pas avoir d'équipe pour livrer un projet déjà vendu, consultez sous-traiter le développement Odoo : qui signe le module.

Questions fréquentes