Une GMAO complète en six métaclasses : comment nous l'avons modélisée sur agis.

Le point de départ

Pourquoi une GMAO

Quand on construit une plateforme qui prétend générer des applications métier à partir de leur modèle, la première question des interlocuteurs est toujours la même : « montrez-moi une vraie application ». Il nous fallait un domaine assez riche pour être crédible — hiérarchies, workflows, planification, historique — et assez répandu pour parler à tout le monde.

La gestion de maintenance coche toutes les cases. Un parc d'équipements localisés, des interventions qui changent d'état, des plans préventifs qui génèrent du travail à échéance, des indicateurs calculés sur l'historique. Et c'est un marché où les outils existants sont souvent rigides : exactement là où le metadriven a quelque chose à prouver.

Étape 1

Le modèle sur une page

Nous avons commencé sans ouvrir le studio : un schéma sur une feuille, avec la règle de ne garder que ce qui est indispensable au premier ordre de travail clôturé. Six classes sont restées.

class Site          : table   nom, adresse
class Localisation  : table   site, parent, nom          arbre
class Equipement    : table   localisation, criticite, miseEnService
class OrdreDeTravail: table   equipement, priorite, statut : workflow
class Tache         : table   ordre, libelle, fait, duree
class PlanDeMaintenance : table equipement, periodicite, gamme

Ce qui n'y est pas est aussi important que ce qui y est : pas de stock de pièces, pas de contrats prestataires, pas de compteurs. Nous savions que le modèle pourrait les accueillir plus tard sans casser l'existant — c'est justement le pari.

Étape 2

Ce qui a été généré, et ce qu'il a fallu ajuster

Dès le modèle saisi, agis a produit le schéma PostgreSQL, les écrans de liste et de saisie de chaque classe, l'API REST documentée et les droits de base. L'arbre des localisations s'est affiché comme un arbre parce que la relation « parent » était déclarée réflexive ; le workflow d'ordre de travail est apparu comme des boutons de transition, avec leurs règles.

Trois choses n'étaient pas bonnes du premier coup, et c'est là que le modèle a été révisé :

• 1 Les tâches étaient une classe à part ; à l'usage, on les crée toujours depuis l'ordre de travail. Elles sont devenues une liste imbriquée de l'OT, ce qui a simplifié l'écran et l'outil MCP.
• 2 La périodicité du plan était un nombre de jours ; il fallait un type duration pour gérer « tous les 6 mois » sans arithmétique fragile. Le type a été ajouté à la plateforme, pas à la GMAO.
• 3 La génération des OT à échéance est un comportement, pas une donnée : elle est décrite comme une règle planifiée sur PlanDeMaintenance, exécutée par le moteur.

Étape 3

Le serveur MCP, sans rien écrire

C'est la partie qui surprend le plus en démo. Le serveur MCP d'agis expose chaque classe du modèle comme un jeu d'outils typés — lister, lire, créer, modifier, exécuter une transition — avec le vocabulaire du modèle et les droits de l'utilisateur connecté. Nous avons branché Claude dessus et tapé :

vous › quels équipements du site de Ris-Orangis ont eu
       plus de deux OT en priorité haute depuis janvier ?

agent › Equipement.list(site = "Ris-Orangis")
       OrdreDeTravail.list(priorite = Haute, depuis = 2026-01-01)
       → 2 équipements : Pompe P-12 (4 OT), Compresseur C-3 (3 OT)

vous › crée un plan de maintenance mensuel sur la P-12

agent › PlanDeMaintenance.create(equipement = P-12, periodicite = 1 mois)
       → plan créé, premier OT généré au 1er octobre

Aucun outil n'a été écrit pour cette conversation. Le seul travail a été de soigner les libellés et descriptions des classes et propriétés dans le modèle : c'est ce que l'agent lit pour comprendre le métier. Une description vague donne un agent qui hésite ; une description précise donne un agent qui trouve.

Bilan

Ce que nous en retenons

• ✓ Le temps s'est passé à modéliser et à tester, pas à coder des écrans. Les trois révisions du modèle ont été des changements de déclaration, appliqués sans redéploiement.
• ✓ Les extensions métier (stock de pièces, contrats, dispositifs médicaux) se sont ajoutées ensuite par héritage ou par nouvelles classes, sans toucher au cœur — voir les pages industrie et santé.
• ✓ La qualité de l'agent IA dépend directement de la qualité du métamodèle. C'est devenu un argument central de la plateforme.
• ! Les écrans générés sont corrects mais standard ; pour le technicien sur mobile, une vue « mes OT du jour » dédiée a été nécessaire. C'est une personnalisation déclarée dans le modèle, mais elle ne vient pas gratuitement.