L'IA écrit une proposition, pas un commit

L'onglet IA Développeur d'un environnement écrit du code de module Odoo dans votre dépôt. Ce qui le rend utilisable plutôt qu'inquiétant tient à une seule décision de conception : il n'écrit jamais dans git.

Tout ce qu'il produit arrive sous forme de changeset — un ensemble de fichiers, un résumé, un message de commit et un rapport — qui reste devant vous jusqu'à ce que vous l'approuviez. C'est l'approbation qui produit un commit, et l'approbation est une action humaine avec sa propre permission.

Démarrer l'agent

L'onglet est protégé par ai.use, et il n'apparaît que sur les environnements dont un dépôt est connecté — sans quoi l'agent n'aurait rien à lire.

Avant une première exécution, vous démarrez un espace de travail d'agent : un vrai clone de votre dépôt, où l'agent peut lancer git, des linters et un diff face à la branche réelle. C'est une condition préalable, et le panneau la place donc au-dessus du composeur plutôt que de vous laisser écrire une consigne pour échouer ensuite. Démarrez-le une fois, il reste disponible pour la conversation.

Trois modes cadrent votre demande : Générer un nouveau module, Modifier du code existant, ou Corriger ce qui est cassé. Ils diffèrent par le fait que l'agent lise ou non les fichiers existants d'abord, et par la façon dont la tâche est posée au modèle — pas par ce qu'ils autorisent.

Ce à quoi l'agent peut toucher, et ce à quoi il ne peut pas

Deux limites méritent d'être connues, car toutes deux existent pour des raisons qu'on préfère ne pas découvrir par accident.

Il refuse de tourner sur le simulateur hors ligne. La plateforme embarque un moteur simulé pour le développement, et une exécution simulée produit un module complet, plausible et inventé, qui ressemble exactement à une vraie proposition dans l'écran de revue. L'agent refuse donc de tourner dessus. Si aucun moteur réel n'est configuré, vous obtenez un refus plutôt qu'une fiction.

Il n'écrit pas hors d'un module Odoo. L'agent lit votre dépôt, et le contenu du dépôt parvient au modèle sous forme de texte — ce qui veut dire qu'une seule ligne hostile committée dans un dépôt pourrait lui demander d'écrire, par exemple, un fichier d'intégration continue. Le commit se fait avec un jeton qui a le droit d'écriture : un chemin est donc un pouvoir. Seuls les fichiers qui appartiennent à un module Odoo sont acceptés — extensions connues, aucun répertoire caché, aucun fichier de build ou de CI, aucun script ni binaire. Tout le reste est refusé avec une raison, avant même d'être retenu.

Le badge, et ce qu'il vaut

Chaque proposition porte un niveau de preuve. C'est la partie qu'il vaut le plus la peine de comprendre, parce que c'est ce qui sépare une revue qui veut dire quelque chose d'une coche verte qui ne veut rien dire.

Il existe six niveaux, chacun incluant les précédents :

La ligne qui compte passe entre vérifié par lecture et installé dans Odoo. Tout ce qui va jusqu'au linter relève de ce que l'on peut dire en lisant le code ; seule une installation, c'est Odoo lui-même qui l'accepte. Chaque rapport le dit dans sa dernière ligne — ce qui a été vérifié, et explicitement ce qui ne l'a pas été.

Attachez un environnement en service et l'agent peut monter plus haut dans l'échelle. Livrez un paquet tests/ et il peut atteindre le sommet. Ni l'un ni l'autre n'est exigé, et ni l'un ni l'autre n'est feint.

Approuver, et les deux choses qui peuvent vous arrêter

Approuver et committer committe les fichiers — sur une nouvelle branche, jamais sur celle contre laquelle ils ont été écrits. Votre branche de base n'est pas touchée, et vous obtenez une branche à relire, fusionner ou supprimer comme une autre.

Deux contrôles passent d'abord, et tous deux refusent par défaut.

Les fichiers ont-ils changé depuis leur vérification ? Si vous les avez modifiés dans le panneau, le badge ne décrit plus ce qui est à l'écran : il décrit ce que l'agent avait produit. Ce n'est pas un verdict plus faible, c'est un verdict sur autre chose, et l'approbation s'arrête plutôt que de laisser un badge vert se lire comme une autorisation. Relancez les contrôles, ou passez outre.

La branche a-t-elle bougé ? La tête de la branche de base est enregistrée au moment où l'agent la lit, et relue à l'approbation. Si quelqu'un a poussé entre-temps, committer à l'aveugle écraserait silencieusement son travail. L'agent peut relire la branche si vous lui demandez d'affiner le changement — ou vous pouvez passer outre, si vous savez que les deux ne se recouvrent pas.

Les deux refus peuvent être outrepassés par un humain qui a lu le code. Le bouton change alors : il dit Committer quand même, dans une autre couleur, parce qu'une décision de sauter un contrôle ne doit pas ressembler au chemin ordinaire.

Committer exige ai.commit, distincte de ai.use. Quelqu'un peut faire tourner l'agent, lire ses propositions et en discuter sans pouvoir rien mettre dans le dépôt — ce qui est une façon raisonnable de laisser plus de monde s'en servir que vous n'en laissez écrire dans votre code.

Quand ça ne se passe pas comme prévu

Abandonner rejette le changement et propose un champ pour dire pourquoi. La raison est facultative ; une justification obligatoire n'en produirait que des vides. Quand elle est donnée, c'est le retour le plus précieux que reçoive la plateforme — quelqu'un a lu le code et n'a pas été d'accord avec tous les contrôles qui étaient passés.

Affiner vaut en général mieux que rejeter. Répondre dans la même conversation produit une nouvelle version du changeset plutôt qu'un changeset neuf ; l'ancienne version est marquée remplacée et la chaîne est conservée, si bien que la v1 et la v2 restent toutes deux lisibles.

Une exécution qui se termine sans modifier de fichier n'est pas un échec. Si vous avez posé une question, vous obtenez une réponse dans la conversation et aucun changeset — le panneau l'étiquette comme telle au lieu d'afficher un diff vide.

Et si le commit lui-même n'aboutit pas, la distinction que fait la plateforme mérite votre confiance : un refus de votre hébergeur git — branche protégée, chemin rejeté, jeton révoqué — met fin au changeset, parce que réessayer n'y changerait rien. Un délai dépassé ou une connexion coupée le remet en attente de revue avec la raison attachée, parce que le résultat est inconnu et que brûler un changement déjà relu pour un hoquet obligerait à repayer toute l'exécution.

Budgets, historique et permissions

La consommation de jetons est comptée par équipe et affichée dans le panneau : le coût d'une exécution est donc visible là où on la lance, et non à la fin du mois.

Les conversations sont conservées par environnement ; le panneau restaure la plus récente à l'ouverture, et l'historique liste les autres. Chaque changement IA committé est également enregistré dans le flux d'audit de la plateforme.

Trois permissions découpent cette surface : ai.use pour faire tourner l'agent, ai.commit pour approuver et committer, et ai.diagnostics pour laisser l'agent lire un environnement en service — états des modules, déploiements, santé, journaux et enregistrements. Cette dernière est une permission à part et ne fait pas partie du rôle développeur : c'est la différence entre un agent qui lit votre code et un agent qui lit les données de vos clients.