ODOOFX · Automatisation des tests Odoo pour Robot Framework
ODOOFX (paquet robotframework-odoofx) est une bibliothèque Robot Framework open source pour l'automatisation des tests Odoo Community et Enterprise : l'API RPC, l'interface web et l'ORM, avec les cinq agents et la méthode Spec-Test-Driven Development déjà éprouvés sur SAP. La version 0.2.0 est sur PyPI : ses deux canaux, l'API RPC (XML-RPC et JSON-2) et le client web (connexion, navigation, lecture des vues, saisie et enregistrement de formulaires, boutons d'action), sont éprouvés en direct sur Odoo 16 et 19. Cette page dit ce qui existe, ce qui se construit et dans quel ordre.
Un ERP qui bouge chaque année, des tests qui doivent suivre
Odoo sort une version majeure par an, chaque entreprise l'enrichit de modules et de personnalisations, et ses API évoluent. Un outillage de test générique voit des pages web ; ODOOFX veut voir des modèles, des champs et des états de workflow.
Une version majeure par an
Menus, libellés et vues changent d'une version à l'autre. ODOOFX vise une seule base de code avec détection de version, plutôt qu'une suite de tests par version à maintenir en parallèle.
Des modules et des personnalisations propres à chaque entreprise
Ventes, stocks, comptabilité, modules communautaires et développements maison : les agents partent de l'instance réelle (modèles, champs, vues) et non d'une description générique d'Odoo.
Des API qui changent de forme
Odoo 19 déprécie /xmlrpc et /jsonrpc au profit de l'API JSON-2, avec un retrait annoncé en version 22. Le canal RPC d'ODOOFX porte déjà les deux voies : XML-RPC jusqu'à Odoo 18, JSON-2 à partir d'Odoo 19.
Trois canaux pour agir et vérifier
Le même principe que SAPFX, qui unifie SAP GUI, Fiori et les API : un test agit par le canal le plus fidèle au parcours de l'utilisateur et vérifie par le canal le plus direct.
Interface web
Le client web Odoo piloté par la bibliothèque Browser (Playwright) : connexion avec preuve de la cible, navigation dans les menus par identifiants externes, lecture des vues, saisie et enregistrement de formulaires (texte, dates, listes de sélection par code, cases à cocher, relations, lignes), boutons d'action et contrôle des statuts. C'est le parcours que vit l'utilisateur. Opérationnel en 0.2.0 : écritures à l'écran fermées par défaut et journalisées, et un formulaire laissé à moitié saisi n'est jamais enregistré par accident. À venir : les boutons qui ouvrent un assistant, les lignes de section et de note, la suppression de ligne.
API RPC
Créer, lire, modifier, rechercher et supprimer des enregistrements, appeler une méthode métier (confirmer, annuler) sans passer par l'écran. Opérationnel depuis la 0.1.0 : écritures fermées par défaut et journalisées, cible prouvée (URL, base, version) avant toute écriture.
Introspection ORM
Lire les champs d'un modèle avec leur type et leurs relations, les modèles dont le nom contient un texte, l'état d'un module, les codes d'un champ de sélection, l'état de workflow d'un enregistrement et l'identifiant derrière un identifiant externe : dans la 0.2.0, éprouvé en lecture sur Odoo 16 (XML-RPC) et 19 (JSON-2). C'est ce que liront les agents pour écrire une spec.
L'application mobile Odoo (Appium) reste hors du périmètre de la première version.
Ce que la 0.2.0 automatise dès aujourd'hui
Trois usages couverts par la version publiée, par l'API comme à l'écran, éprouvés sur Odoo 16 et 19.
Tests de non-régression par l'API
Rejouer un parcours métier (devis, confirmation, envoi, annulation) par XML-RPC ou JSON-2, ou à l'écran dans le client web (saisie d'un contact, saisie puis confirmation d'un devis par son bouton), et vérifier les codes d'état, quelle que soit la langue de l'interface. La même couche métier, neutre de version, tourne sur Odoo 16 et 19.
Des données de test propres et traçables
Chaque enregistrement créé porte un marqueur de run ; chaque écriture est journalisée (prévue, faite, échouée, inconnue) et sa disparition se prouve sur l'enregistrement identifié. Les écritures restent fermées tant que la connexion ne les autorise pas.
Droits d'accès et preuve de la cible
Vérifier qu'un utilisateur appartient, ou non, à un groupe désigné par son identifiant externe, et prouver l'URL, la base et la version d'Odoo avant la moindre écriture : deux versions d'Odoo peuvent tourner côte à côte sans risque de confusion.
Cinq agents, une méthode commune
ODOOFX applique le Spec-Test-Driven Development défini dans rf-test-agents : la spécification, écrite en langage humain et confrontée à l'instance Odoo vivante, pilote le test ; le test pilote la bibliothèque. Même logique que TDD, une brique plus tôt : la spec, verte par défaut en théorie, est confrontée au système réel avant le moindre test. Les agents ont mené la première campagne (deux plans observés sur Odoo 16 et 19, quinze suites RPC générées et jouées en direct, une revue indépendante en lecture seule et une revue ISTQB), puis une seconde : huit suites web et ORM jouées en direct, dont six relues par la revue indépendante et la revue ISTQB. Ils vivent dans un dépôt atelier privé, avec un plugin rf-mcp et la surcouche odoofx-mcp ; PyPI et le dépôt public livrent la bibliothèque.
odoo-planner
Confronte la spec humaine (objectif, user story, scénario BDD, suite existante) à l'instance réelle : vues, modèles et champs ORM, états de workflow. Il en écrit la version observée dans specs/, relue par un humain.
odoo-generator
Produit la suite Robot Framework à partir du plan, chaque étape exécutée en direct avant d'être écrite, et la scelle par l'empreinte SHA256 du plan : un plan modifié sans régénération fait échouer le garde.
odoo-healer
Répare la couche resources/, jamais le test ni ses assertions. Budgets fixés (2 candidats, 20 appels, 900 secondes) et cinq verdicts, dont application_defect quand c'est Odoo qui a changé.
odoo-istqb
Conçoit des plans et des cas de test ISTQB rejouables, et relit chaque suite générée : traçabilité des exigences, valeurs limites, transitions d'état, indépendance et maintenabilité, avec un verdict daté.
odoo-verifier
Revue indépendante en lecture seule : fidélité de l'exécution, justesse des verdicts, couverture tenue par rapport à la promesse du plan. Il n'écrit rien et ne peut pas être influencé.
Des données de test valides, qui ne quittent pas le poste
Trois besoins concrets des tests d'ERP, inscrits au backlog et cadrés le 23 septembre 2026. Rien de tout cela n'est encore implémenté.
Identifiants métier valides par construction
SIREN, SIRET, numéro de TVA intracommunautaire et IBAN fictifs mais valides, fournis par un paquet Robot Framework partagé avec SAPFX. Une graine journalisée permet de rejouer un échec avec la même donnée.
Devis, factures et bons de livraison lus en PDF
Le PDF est récupéré par la route de rapport d'Odoo avec la session authentifiée, puis son texte est vérifié. Un PDF sans couche texte échoue en le disant, jamais par une lecture vide.
Une boîte mail de test locale
Le serveur SMTP sortant d'Odoo pointe vers une boîte Mailpit en conteneur local, lue par son API : attente bornée d'un message, contenu, liens. Jamais une boîte publique.
Du socle à la version 1.0, dans cet ordre
État au 13 octobre 2026. Les échéances sont des objectifs, pas des engagements.
Socle du projet · en place
Dépôt public, licence Apache 2.0, intégration continue, garde de rédaction, mémoire du projet et définition des cinq agents. Deux instances Odoo de test (16 et 19) sont provisionnées avec leurs données de démonstration.
Canal RPC de la bibliothèque · livré en 0.1.0
Lecture, écriture fermée par défaut et journalisée, appel de méthodes métier, preuve de la cible ; XML-RPC jusqu'à Odoo 18, JSON-2 à partir d'Odoo 19. Les trente premiers keywords documentés.
Première campagne en direct · faite le 1er octobre 2026
Le devis de vente, du plan observé à la suite jouée : 15 suites RPC et 65 tests sur Odoo 16 et 19 (création, confirmation, envoi, annulation et retour arrière, droits, article stocké), générés par les agents et relus par une revue indépendante.
Distribution · 0.1.0 le 5 octobre 2026, 0.2.0 le 13 octobre 2026
Paquet robotframework-odoofx sur PyPI (0.1.0 le 5 octobre, 0.2.0 le 13 octobre), documentation des keywords en ligne et dépôt public synchronisé.
Canal web et introspection de l'ORM · livrés en 0.2.0
Par la bibliothèque Browser : connexion avec preuve de la base et de la série, navigation par identifiants externes de menus, lecture des vues et des enregistrements, saisie et enregistrement de formulaires (dates, listes de sélection, cases à cocher, relations, lignes), boutons d'action, déconnexion ; en lecture, les champs, les relations, les modèles et les états de modules par RPC. 69 keywords documentés, 68 avec un exemple rejoué en Robot Framework. Seconde campagne : huit suites web et ORM, 52 tests joués en direct sur Odoo 16 et 19 du 8 au 13 octobre 2026.
Agents outillés · plugin livré, suite à venir
Le plugin rf-mcp et la surcouche odoofx-mcp (état de session : connexion RPC, session web, formulaire non enregistré, journal des écritures) existent dans l'atelier privé et ont passé 19 contrôles sur 19 de bout en bout sur Odoo 16 et 19. À venir : l'état d'un enregistrement par l'ORM et une première réparation de suite par odoo-healer, qui n'a encore réparé aucune suite.
Couverture du canal web · à venir
Les boutons qui ouvrent un assistant, les lignes de section et de note, la suppression de ligne, les champs numériques formatés et un produit stockable saisi à l'écran, chacun avec sa preuve en direct sur Odoo 16 et 19 avant toute publication.
Multi-versions et intégration continue · à venir, visé fin 2026
La détection de version existe ; restent l'adaptation à chaque version, la correspondance des menus et des libellés, la mesure sur Odoo 14, 15, 17 et 18 (aujourd'hui 16 et 19 seulement), des instances Docker décrites dans le dépôt et une matrice de CI sur les versions ciblées.
Version 1.0 · visée 2027
Signatures stabilisées, fonctions prises en charge documentées version par version, versions ciblées mesurées. Les échéances sont des objectifs, pas des engagements.
Installer depuis PyPI, en une commande
Le paquet robotframework-odoofx s'installe depuis PyPI (Python 3.10 ou plus, Robot Framework 7.4 ou plus) et la documentation de ses 69 keywords est en ligne. Les identifiants passent par la ligne de commande, jamais par une suite.
# Installer la bibliothèque depuis PyPI
pip install robotframework-odoofx
# Option : la bibliothèque Browser, pour le canal web
pip install "robotframework-odoofx[web]"
rfbrowser init # navigateurs Playwright, une seule fois*** Settings ***
Library OdooFxLibrary
*** Test Cases ***
Lire l'état d'un devis
Connect To Odoo http://localhost:8069 ma_base admin ${PASSWORD} channel=xmlrpc
Assert Quotation Status Is sale S00004
[Teardown] Disconnect From Odoo
# Lancement : le secret passe par la ligne de commande
# robot -v "PASSWORD: Secret:<secret>" lire_devis.robotComprendre ODOOFX
Les réponses courtes aux questions qu'on nous pose sur l'état du projet, les versions visées et la place d'ODOOFX dans l'écosystème AI Cabra.
Où en est ODOOFX aujourd'hui ?
ODOOFX est en phase alpha, version 0.2.0, publiée sur PyPI le 13 octobre 2026 (la 0.1.0 date du 5 octobre). Deux canaux fonctionnent et sont éprouvés en direct sur Odoo 16 et Odoo 19. Le canal RPC : lecture, écriture fermée par défaut et journalisée, preuve de la cible, par XML-RPC jusqu'à Odoo 18 et par l'API JSON-2 à partir d'Odoo 19. Le client web, par la bibliothèque Browser : connexion avec preuve de la cible, navigation par identifiants externes de menus, lecture des vues, saisie et enregistrement de formulaires, boutons d'action. 23 suites et 117 tests ont été joués sur les deux instances (55 sur Odoo 16, 62 sur Odoo 19), écrits à partir de plans observés sur les instances. Pas encore couverts : les boutons qui ouvrent un assistant, les lignes de section et de note, la suppression de ligne. Aucun résultat sur une instance client n'est revendiqué.
- Code ouvert dès le premier jour : le dépôt public reflète l'état réel, sans vitrine.
- Des chiffres mesurés, pas anticipés : chaque résultat publié dit son périmètre et ses limites.
Quelles versions d'Odoo ODOOFX vise-t-il ?
Odoo Community et Enterprise, depuis la version 14, avec une seule base de code et une détection de version plutôt qu'une branche par version. Le développement s'appuie sur Odoo 16, dernier client web historique, et sur Odoo 19, la plus récente : ce sont les deux versions éprouvées à ce jour. Odoo 19 déprécie les points d'entrée /xmlrpc et /jsonrpc au profit de l'API JSON-2, avec un retrait annoncé en version 22 : la bibliothèque parle XML-RPC jusqu'à Odoo 18 et JSON-2, avec une clé API, à partir d'Odoo 19.
- Deux générations de référence : Odoo 16 et Odoo 19 en conteneurs locaux.
- API anticipée : JSON-2 en service avant le retrait des anciens points d'entrée.
Pourquoi tester Odoo par l'API et l'ORM en plus de l'interface ?
L'interface prouve le parcours de l'utilisateur, mais elle est lente et sensible aux changements d'affichage. Les appels RPC préparent les données et vérifient l'état réel des enregistrements sans passer par l'écran ; l'introspection ORM fournit aux agents les modèles, les champs et les états de workflow réels plutôt que des hypothèses. Un même test peut ainsi agir par l'interface et contrôler par l'API.
- Agir par l'écran, vérifier par l'API : un contrôle qui ne dépend pas de l'affichage.
- Des specs fondées sur l'instance : les agents lisent l'ORM, ils ne devinent pas.
Comment ODOOFX s'articule-t-il avec SAPFX et rf-test-agents ?
rf-test-agents définit la méthode commune : le Spec-Test-Driven Development et le contrat des cinq agents. SAPFX l'applique à SAP, ODOOFX à Odoo, sans la forker : une amélioration de méthode trouvée sur Odoo remonte dans rf-test-agents puis redescend dans les autres verticales. ODOOFX apporte ce qui est propre à Odoo : perception ORM, canaux RPC, lecture des vues et des états de workflow.
- Une méthode, plusieurs ERP : les mêmes agents raisonnent de la même façon sur SAP et sur Odoo.
- Aucune dépendance de code : chaque verticale garde son cycle de vie.
Résultats mesurés et périmètre de validation
Tester Odoo avec Robot Framework par l'API RPC et par l'interface web, avec l'introspection de l'ORM. Revu le 13 octobre 2026. Les sources publiées et les conditions de mesure sont précisées ci-dessous.
- 117 tests en direct sur Odoo 16 et 19 23 suites jouées sur deux instances Docker de développement entre le 1er et le 13 octobre 2026 : 55 tests sur Odoo 16, 62 sur Odoo 19. Le flux RPC du devis de vente (15 suites, 65 tests : création, confirmation, envoi, annulation et retour arrière, droits d'un commercial, article stocké, cas négatifs, joués le 1er octobre) ; le client web (exploration en lecture, saisie d'un contact, saisie et confirmation d'un devis à l'écran) et l'introspection de l'ORM (8 suites, 52 tests, joués du 8 au 13 octobre). Aucune instance client. Exécutions internes du 01/10 au 13/10/2026
- 0.2.0 publiée sur PyPI Publiée le 13 octobre 2026, après la 0.1.0 du 5 octobre : pip install robotframework-odoofx, Python 3.10 à 3.14, Robot Framework 7.4 ou plus. Installée depuis PyPI dans un environnement neuf, elle expose ses 69 keywords. Phase alpha : les signatures peuvent encore changer avant la 1.0. Paquet robotframework-odoofx sur PyPI
- 69 keywords documentés Canaux RPC et web et introspection de l'ORM, tous documentés par Libdoc ; le 69e, Create New Quotation, est un squelette qui se contente d'avertir. XML-RPC jusqu'à Odoo 18, JSON-2 à partir d'Odoo 19 ; client web par la bibliothèque Browser. Non couverts : les boutons qui ouvrent un assistant, les lignes de section et de note, la suppression de ligne. Documentation des keywords (Libdoc)
- 68 exemples rejoués en Robot Framework Chacun des 68 keywords qui ne sont pas un squelette porte un exemple d'utilisation, rejoué tel qu'écrit dans Robot Framework contre Odoo 16 le 13 octobre 2026 (68 sur 68, rien laissé sur l'instance). Un registre d'empreintes interdit qu'un exemple change sans être rejoué. Mesure interne, sans instance client. Rejeu interne du 13/10/2026
- 849 tests unitaires Relevé du 13 octobre 2026 sur le poste de développement, hors Odoo : ils vérifient la bibliothèque contre des doubles locaux d'Odoo, l'export public, les gardes du dépôt et le registre des exemples rejoués, pas une instance Odoo. Mesure interne du 13/10/2026
- 19 contrôles de bout en bout via rf-mcp Le plugin rf-mcp d'ODOOFX et sa surcouche odoofx-mcp, avec un outil d'état de session (connexion RPC, session web, formulaire non enregistré, journal des écritures), ont passé 19 contrôles sur 19 à travers les outils réels de rf-mcp 0.36, sur Odoo 16 puis sur Odoo 19, en lecture seule. Outillage de l'atelier privé, absent du paquet PyPI. Contrôle interne du 13/10/2026
Vous testez Odoo, ou vous allez devoir le faire ?
Montée de version, modules sur mesure, recette d'un projet d'intégration : parlons de vos parcours critiques. Vos cas réels orientent la feuille de route d'ODOOFX.
- Un échange technique, pas commercial
- Vos données restent en France