Créer un module Odoo avec l'IA : du besoin au déploiement contrôlé

Dans Odoo Community, personnaliser veut dire écrire des modules : l'outil de personnalisation visuelle de l'éditeur est réservé à la version Enterprise. L'IA sait aujourd'hui produire ce code. La vraie question est ailleurs : comment passer d'un besoin exprimé en français à un module installé en production, sans jamais mettre la production en danger ? Voici le parcours, étape par étape.

1. Bien formuler le besoin

Un agent développeur comprend le langage courant, mais un besoin précis donne un module juste du premier coup. Une bonne demande dit :

• sur quel objet : les contacts, les devis, les factures, les événements ;
• quelle information ou quel comportement : un champ texte, une date, une liste de choix, une règle ;
• quelles contraintes : obligatoire, unique, calculé, modifiable par qui ;
• où l'afficher : sur la fiche, dans la liste, dans un filtre, sur un document imprimé.

« Ajoute un champ sur les clients » laisse trop de questions ouvertes. « Ajoute un numéro de dossier unique sur les contacts, visible sous le numéro de TVA, et affiche-le sur les devis » se transforme directement en spécification.

2. Lire l'existant avant d'écrire

Une instance Odoo en production n'est jamais vierge. D'autres modules ont pu ajouter un champ portant le même nom, hériter de la même vue ou modifier le même comportement. Avant de produire la moindre ligne, l'agent développeur explore donc les modules installés et le code de vos propres modules personnalisés : quels modèles existent déjà, quelles vues sont déjà héritées, de quels modules dépendre.

Cette étape d'exploration évite les conflits les plus fréquents : deux définitions concurrentes d'un même champ, une vue qui casse parce qu'un autre module a déplacé l'élément de référence, une dépendance oubliée dans le manifeste qui fait échouer l'installation sur une autre base. C'est aussi elle qui permet de corriger un bug dans vos développements existants plutôt que d'empiler un module de plus.

3. Ce que l'agent produit : un module Odoo standard

Le résultat n'est pas un script opaque, mais un module comme en écrit un développeur Odoo :

• __manifest__.py : le nom, la version, les dépendances (sale, par exemple) et la liste des fichiers chargés ;
• models/ : les champs et modèles, en Python, par héritage des modèles existants ;
• views/ : les vues formulaire, liste et recherche, en XML, par héritage des vues existantes ;
• security/ : les droits d'accès, dès qu'un nouveau modèle est créé ;
• tests/ : les tests automatisés.

Pour notre exemple, le cœur du module tient en quelques lignes. Odoo 19 déclare désormais les contraintes SQL avec models.Constraint :

from odoo import fields, models


class ResPartner(models.Model):
    _inherit = 'res.partner'

    numero_dossier = fields.Char("Numéro de dossier", copy=False, index=True)

    _numero_dossier_unique = models.Constraint(
        'UNIQUE(numero_dossier)',
        "Ce numéro de dossier est déjà attribué à un autre contact.",
    )

La vue hérite du formulaire des contacts et place le champ après le numéro de TVA :

<record id="view_partner_form_numero_dossier" model="ir.ui.view">
    <field name="name">res.partner.form.numero_dossier</field>
    <field name="model">res.partner</field>
    <field name="inherit_id" ref="base.view_partner_form"/>
    <field name="arch" type="xml">
        <field name="vat" position="after">
            <field name="numero_dossier"/>
        </field>
    </field>
</record>

Les vues d'Odoo 19 suivent aussi une syntaxe plus récente que celle de nombreux exemples encore en circulation : balise list au lieu de tree, attributs invisible et readonly écrits comme des expressions plutôt que dans attrs. Un générateur qui s'appuie sur la version réellement installée évite ces anachronismes.

4. Les tests, avant toute proposition

Un module qui « a l'air juste » n'est pas un module testé. L'agent écrit des tests automatisés avec le cadre de test d'Odoo, puis installe le module et exécute ces tests dans un bac à sable isolé : une base jetable, sans réseau, sans accès à votre production ni à vos secrets.

from psycopg2 import IntegrityError

from odoo.tests import TransactionCase, tagged
from odoo.tools import mute_logger


@tagged('post_install', '-at_install')
class TestNumeroDossier(TransactionCase):

    def test_numero_unique(self):
        self.env['res.partner'].create({'name': "Client A", 'numero_dossier': "D-001"})
        with self.assertRaises(IntegrityError), mute_logger('odoo.sql_db'):
            self.env['res.partner'].create({'name': "Client B", 'numero_dossier': "D-001"})

On teste ce qui compte pour le métier : la contrainte d'unicité, l'affichage au bon endroit, et le comportement selon les droits de l'utilisateur. Si un test échoue, l'agent corrige et relance, avant de vous présenter quoi que ce soit.

5. Une branche Git par tâche

Chaque tâche de développement vit sur sa propre branche Git. L'intérêt est très concret : le changement proposé est un ensemble de fichiers clairement délimité, l'historique montre ce qui a été modifié et pourquoi, et une évolution peut être reprise ou abandonnée sans toucher aux autres.

6. Le déploiement contrôlé

Un module testé n'est encore qu'une proposition. Le passage en production suit un protocole strict :

1. Validation explicite par un administrateur autorisé : formuler une demande ne suffit pas pour déployer.
2. Sauvegarde préalable de la base de données et de la version précédente du module.
3. Installation ou mise à jour du module, puis redémarrage du service.
4. Vérification que l'instance répond et que le module est bien installé.
5. Retour arrière en un clic si le résultat ne convient pas.

Un conseil d'expérience : vérifiez le résultat juste après le déploiement, sur un cas réel. Plus un éventuel problème est repéré tôt, plus le retour arrière est simple, puisqu'il y a moins de saisies faites entre-temps à reprendre.

Ce que l'IA fait bien, et quand appeler un développeur

L'IA accélère les évolutions courantes ; l'architecture d'un projet structurant reste un travail d'expert. Chez SHAU, les petites modifications commencent à 90 € HT et les modules personnalisés à 490 € HT ; les projets complexes sont chiffrés sur devis (détail des tarifs).

En résumé

Créer un module Odoo avec l'IA est fiable à une condition : que la génération du code soit séparée de son déploiement. Besoin précis, module standard, tests en bac à sable, branche par tâche, validation humaine, sauvegarde et retour arrière : c'est le parcours de l'agent développeur de SHAU AI. Plus de détails sur le développement de modules Odoo avec l'IA, et sur les règles de sécurité dans notre article dédié.