Vous avez branché un assistant IA sur votre base Odoo 20.0 la semaine dernière, en lecture seule. Depuis un changement du module ai_mcp intégré le 10 novembre, ce même assistant peut créer et modifier des enregistrements sans que vous ayez coché quoi que ce soit. C'est le premier des trois changements que j'ai retenus dans odoo/enterprise pour la semaine du vendredi 6 au jeudi 12 novembre 2026, avec un correctif sur les arrondis de la liasse 2033 et un autre sur les accès en lecture seule à la comptabilité. Le conseil d'exploitation qui suit s'adresse à ceux qui hébergent Odoo eux-mêmes : il existe une adresse prévue pour savoir si le serveur répond, et elle ne demande presque rien pour servir.
Trois changements de la semaine
Le serveur MCP expose la création et la modification par défaut
Dans le module ai_mcp d'odoo/enterprise, un commit intégré le 10 novembre sur la branche 20.0 rend deux outils supplémentaires disponibles d'office pour les clients MCP : « AI Tool: Create Records » et « AI Tool: Update Records ». Selon le message du commit, seuls les outils de lecture étaient exposés, les utilisateurs qui essayaient le serveur MCP d'Odoo le croyaient donc en lecture seule, et activer l'écriture obligeait à reconnecter le client, ce sur quoi les démonstrations trébuchaient régulièrement.
Je comprends l'argument commercial et je ne partage pas le choix. Dans l'article de la semaine dernière sur le serveur MCP d'Odoo 20, j'écrivais qu'une base fraîchement installée ne permettait à un agent d'écrire quoi que ce soit, et que tout ce qui dépassait la lecture résultait d'un choix de l'administrateur. Cette phrase n'est plus vraie pour une base 20.0 dont le module a été mis à jour après le 10 novembre. La documentation officielle, consultée le 13 novembre, liste encore cinq outils de lecture par défaut ; elle n'a pas suivi le code.
Le fichier de données modifié n'est pas marqué comme protégé contre les mises à jour. D'après ce que je lis du code, une base existante reçoit donc le nouveau réglage quand le module est mis à jour, et pas seulement une base neuve. En Online, cette mise à jour se fait sans vous ; sur Odoo.sh et sur site, elle suit la mise à jour de la branche Enterprise et des modules. Le réglage prudent reste accessible : mode développeur, Paramètres ‣ Technique ‣ Actions serveur, puis décocher « Disponible dans MCP » sur les deux outils d'écriture si vous voulez revenir à la lecture seule. Le client MCP garde la liste des outils pendant sa session, il faudra le reconnecter pour qu'il voie la différence. Au 12 novembre, le changement est sur la branche 20.0 seulement.
La liasse 2033 arrondit après avoir additionné
Dans l10n_fr_reports, un correctif intégré le 8 novembre en 20.0 et en 19.4 reprend le calcul des sous-totaux des tableaux 2033-A (bilan simplifié) et 2033-B (compte de résultat simplifié). Chaque ligne arrondissait son solde à l'euro, et les lignes parentes additionnaient ces valeurs déjà arrondies. Trois lignes de 0,33 affichaient donc 0 chacune, et leur total affichait 0 au lieu de 1. Le message du commit cite la notice 2033-NOT-SD de la DGFiP : les montants s'inscrivent sans centimes, « y compris les totalisations », ce qui signifie que l'on arrondit un total après l'avoir calculé, et non que l'on additionne des arrondis. Le même défaut produisait des écarts entre l'actif et le passif de la déclaration.
Il y a deux semaines, je signalais déjà un correctif sur les formules de ces deux tableaux ; celui-ci corrige autre chose, et la conclusion ne bouge pas : une liasse 2033 extraite d'Odoo 20 ou 19.4 avant ces dates mérite une comparaison avec les chiffres de votre expert-comptable. NXL Forge a publié le 6 novembre une liste de tests à mener en novembre pour une première clôture sur Odoo 20.
Un utilisateur en lecture seule peut ouvrir les déclarations
Deux commits intégrés le 6 novembre en 20.0, dans account_reports et accountant, corrigent le quotidien des utilisateurs du groupe « Afficher les fonctionnalités de comptabilité - Lecture seule », celui que l'on donne souvent à un expert-comptable ou à un dirigeant qui veut consulter sans toucher. Le premier : le menu des déclarations fiscales leur renvoyait une erreur d'accès, alors que la même page s'ouvrait en tapant son adresse directement. L'action serveur derrière le menu ne donnait le droit d'exécution qu'aux comptables ; elle l'accorde maintenant aussi au groupe de lecture seule. Le second : l'entrée « Tableau de bord » du menu Comptabilité leur était cachée, rattachée par erreur au groupe des utilisateurs de facturation ; elle redevient visible.
Ce sont de petits correctifs. Si vous avez expliqué à votre cabinet comptable qu'il « n'avait pas le droit » d'ouvrir les déclarations, c'était pourtant un bug, pas un choix de droits. Je n'ai trouvé ces deux commits que sur la branche 20.0 au 12 novembre.
Savoir que votre Odoo ne répond plus avant vos utilisateurs
Quand un Odoo sur site tombe, la première personne à le savoir est souvent celle qui n'arrive pas à ouvrir un devis à 8 h 30. Odoo embarque pourtant une adresse prévue pour un contrôle automatique : /web/health. Elle est définie dans le module web d'odoo/odoo, en 19.0 comme en 20.0. Elle ne demande aucune authentification, elle ne crée pas de session, et elle répond en JSON avec {"status": "pass"} et un code 200 quand le processus Odoo est capable de traiter une requête HTTP.
Un paramètre complète le contrôle : ?db_server_status=1. Odoo ouvre alors une connexion au serveur PostgreSQL et la referme. Si la connexion échoue, la réponse passe à "status": "fail" avec un code 500. Les tests automatisés du module vérifient ce comportement, et aussi qu'aucun cookie de session n'est posé.
Ce contrôle concerne les installations sur site et les serveurs loués. Sur Odoo.sh, l'onglet Monitor de chaque build affiche les métriques de performance, et la documentation recommande de rester en UTC pour les rapprocher des journaux. En Online, Odoo publie l'état de ses services sur sa page de statut publique ; vous ne surveillez pas un serveur, vous surveillez l'éditeur.
Avant d'appliquer ces conseils : testez chaque manipulation sur une copie de votre base ou sur un serveur de test, jamais directement en production. Ces conseils sont rédigés sans connaître votre configuration et peuvent ne pas s'appliquer tels quels chez vous. Nexelans ne peut pas être tenue responsable des conséquences d'une manipulation faite sans ces précautions.
Pour vérifier à la main, deux commandes suffisent, à lancer depuis un poste extérieur au serveur pour tester en même temps le serveur web frontal et le certificat :
curl -s https://erp.exemple.fr/web/health
curl -s -o /dev/null -w '%{http_code}\n' 'https://erp.exemple.fr/web/health?db_server_status=1'
La première doit afficher {"status": "pass"}, la seconde 200. Pour en faire une surveillance, le plus simple est de confier cette adresse à l'outil de supervision que vous utilisez déjà, celui qui surveille peut-être votre site web ou votre messagerie, en lui demandant d'alerter si le code n'est pas 200 ou si le corps ne contient pas pass. Si vous n'avez rien de tel, un script lancé toutes les cinq minutes par cron depuis une autre machine fait l'essentiel :
#!/bin/bash
# /usr/local/bin/odoo-health.sh : alerte si Odoo ne répond plus
URL='https://erp.exemple.fr/web/health?db_server_status=1'
code=$(curl -s -m 10 -o /tmp/odoo-health.json -w '%{http_code}' "$URL")
if [ "$code" != "200" ] || ! grep -q '"pass"' /tmp/odoo-health.json; then
echo "Odoo ne répond pas (code $code) : $(cat /tmp/odoo-health.json 2>/dev/null)" \
| mail -s "[ALERTE] Odoo erp.exemple.fr" admin@exemple.fr
fi
Le délai de dix secondes compte autant que le code de retour : un Odoo qui répond en quinze secondes est, pour vos utilisateurs, un Odoo en panne. Testez-le une fois en pointant sur une adresse fausse, pour voir l'email arriver.
Ce que cette adresse ne dit pas
Le contrôle répond à une question, et une seule : un worker HTTP est-il capable de traiter une requête, et, avec le paramètre, le serveur PostgreSQL accepte-t-il une connexion ? Il ne détecte pas une file d'attente qui s'allonge parce que tous les workers sont occupés, tant que la requête finit par passer dans le délai. Il ne vérifie pas que les actions planifiées tournent ni que les emails partent, ce que j'ai décrit dans l'article sur la surveillance des crons et des emails. Et la connexion testée avec db_server_status vise le serveur PostgreSQL, pas votre base en particulier : une base verrouillée par une migration en cours passerait ce contrôle.
Mon avis : c'est précisément parce qu'il est pauvre que ce contrôle est utile. Il ne se trompe presque jamais, et il transforme « le serveur est tombé dans la nuit » en un email reçu à 3 h 12, lu à 7 h et réglé avant l'arrivée des commerciaux. Les contrôles plus riches viennent ensuite, un par un, quand une panne vous a montré ce qui manquait.
Sources
- odoo/odoo 20.0, module web, contrôleur home.py (route /web/health) et tests test_health.py (consultés le 13/11/2026) : Lire le code
- Documentation Odoo 20.0, Odoo.sh, branches : onglet Monitor (consultée le 13/11/2026) : Lire la documentation
- Documentation Odoo 20.0, serveur MCP : outils exposés par défaut (consultée le 13/11/2026) : Lire la documentation
- DGFiP, notice 2033-NOT-SD, millésime 2026 : Lire la notice
- Page de statut des services Odoo : Voir la page
- odoo/enterprise, module ai_mcp, commit intégré le 10/11/2026 en 20.0 (outils Create Records et Update Records disponibles dans MCP par défaut)
- odoo/enterprise, module l10n_fr_reports, commit intégré le 08/11/2026 en 20.0 et 19.4 (arrondi après sommation des tableaux 2033-A et 2033-B)
- odoo/enterprise, modules account_reports et accountant, commits intégrés le 06/11/2026 en 20.0 (accès en lecture seule aux déclarations fiscales et au tableau de bord)
- NXL Forge, « Clôture 2026 sous Odoo 20 : amortissements et plaquette à revoir » (06/11/2026) : Lire l'article