Odoo 19 Studio peut recevoir l’événement d’un système externe par requête POST, puis exécuter une action dans l’ERP. Une automatisation peut également envoyer une notification webhook lorsqu’un événement survient dans Odoo. Cette architecture évite d’attendre une tâche planifiée, mais transforme une simple URL en point d’entrée métier.
Pour une PME belge ou française, le besoin peut être concret : créer un contact qualifié, synchroniser un statut de commande ou déclencher un traitement logistique. L’enjeu n’est pas de réussir une démonstration ; il est de garantir que le flux reste sûr, traçable et récupérable en production.
Ce que fournit Odoo 19
Dans Studio, un webhook entrant associe une URL générée, un modèle cible, une logique de recherche de l’enregistrement et une ou plusieurs actions. Odoo précise qu’une connexion entre deux bases Odoo peut être configurée sans code, tandis qu’une cible ou une action personnalisée peut demander du développement. Pour un système non-Odoo, la correspondance entre le JSON reçu et l’enregistrement cible doit être adaptée.
La journalisation des appels peut être activée. Le secret intégré à l’URL peut être renouvelé avec Rotate Secret ; Odoo avertit que cette URL est confidentielle et qu’une rotation impose de la mettre à jour dans le système émetteur. Côté sortant, l’action Send Webhook Notification envoie les champs choisis par POST et affiche un exemple de charge utile.
Une URL secrète n’est pas un modèle de gouvernance
Réduire l’effet d’un appel indésirable
Le secret doit être stocké comme un identifiant sensible, jamais dans un ticket public, une capture d’écran ou un dépôt de code. Le contrôle essentiel reste l’action autorisée derrière l’URL. Une règle qui modifie seulement le statut vérifié d’une commande identifiée expose moins qu’une action générique capable de créer ou modifier plusieurs objets.
Valider avant d’écrire
Le flux doit refuser les charges incomplètes, les références inconnues et les transitions métier impossibles. Les identifiants externes doivent être stables et distincts des identifiants techniques internes. Si l’émetteur renvoie un événement après un délai réseau, une clé d’idempotence ou un registre d’événements doit empêcher une seconde facture, livraison ou fiche contact.
Ne pas confondre journal technique et piste d’audit
Les journaux d’appel aident à diagnostiquer une erreur, mais l’entreprise doit aussi relier l’événement externe, la décision prise et l’écriture Odoo créée. Pour les flux financiers ou logistiques, conservez un identifiant de corrélation, un état, la date et le résultat, avec une durée de conservation adaptée aux données transportées.
Tester le comportement, pas seulement le code 200
La documentation Odoo recommande de configurer et tester le webhook sur une copie de la base avant la production. Un retour 200 OK ou status: ok indique que l’appel fonctionne côté Odoo ; il ne prouve pas que la bonne règle métier a été exécutée une seule fois.
La recette doit couvrir le message nominal, les champs absents, le mauvais type de donnée, la référence inconnue, le doublon, les événements désordonnés et l’indisponibilité du système suivant. Testez aussi la rotation du secret : qui change l’URL, comment la nouvelle valeur est distribuée et comment détecter les appels envoyés vers l’ancienne ?
Quand Studio suffit — et quand développer
Studio convient à une action courte, ciblée, réversible et à faible volume lorsque le contrat est stable. Une couche d’intégration ou un module dédié devient préférable s’il faut vérifier une signature supplémentaire, orchestrer plusieurs objets de façon atomique, gérer une file et des reprises, transformer fortement les données ou versionner le contrat.
Cette frontière s’aligne avec la stratégie d’API Odoo JSON-2 : webhook pour notifier un événement, API pour lire ou exécuter un contrat explicite, module serveur lorsque la transaction métier doit rester indivisible.
Analyse Underside : exploiter chaque webhook comme un mini-produit
Nous recommandons une fiche d’exploitation par webhook : propriétaires métier et technique, environnement, émetteur, modèle et action Odoo, schéma du message, données sensibles, volume, règles de doublon, délai maximal, alertes, rotation et procédure de désactivation.
Dans un groupe franco-belge, définissez également la société concernée et les données autorisées par entité. Un événement valide pour une société ne doit pas en sélectionner implicitement une autre. Les droits d’accès et la séparation des responsabilités restent une partie du contrat d’intégration.
Contrôles avant production
- Attribuer des propriétaires métier et technique.
- Documenter le JSON, les champs obligatoires et les transitions permises.
- Limiter l’action au modèle, à la société et aux enregistrements nécessaires.
- Protéger l’URL, organiser sa rotation et tester sa révocation.
- Rendre le traitement idempotent et tracer un identifiant de corrélation.
- Tester doublons, désordre, erreurs, délais, reprises et indisponibilités.
- Choisir un module ou une couche d’intégration lorsque Studio ne suffit plus.
Sources officielles
- Odoo 19 — créer, sécuriser, journaliser et tester des webhooks.
- Odoo 19 — règles d’automatisation et notifications webhook.
Underside accompagne le cadrage et l’intégration de flux Odoo en Belgique et en France, de la règle Studio ciblée au connecteur supervisé. L’objectif est qu’un événement temps réel reste un processus métier contrôlable.