Quand l'entreprise change, l'ontologie doit changer avec elle

Une entreprise qui a toujours vendu des produits commence à vendre, en plus, des contrats de service. Un contrat de service n’entre pas dans la notion de commande : il n’y a rien à livrer, il est facturé chaque mois, et il s’accompagne de délais d’intervention que l’entreprise doit tenir. La solution la plus rapide : une commande avec un code type spécial et quelques champs de texte libre pour les conditions du contrat.

Un an plus tard, les rapports comptent les contrats de service comme des commandes et gonflent le carnet de commandes. L’entrepôt voit des commandes sans articles et demande quoi préparer. Un agent chargé de préparer les bons de livraison de la semaine en produit un pour un contrat de maintenance. Chaque problème reçoit son petit correctif, et chaque correctif rend le changement suivant plus difficile.

La cause : le modèle métier a été traité comme une infrastructure figée, conçue une fois puis défendue. Or une ontologie décrit le fonctionnement de l’entreprise, et l’entreprise change en permanence : réorganisations, nouveaux produits, acquisitions, nouvelles réglementations, nouvelles façons de vendre. Si le modèle ne peut pas évoluer en sécurité, les personnes le feront évoluer sans sécurité, un code type à la fois.

Comment un modèle métier se périme

La surcharge. Un objet existant est réutilisé pour quelque chose de nouveau, distingué par un indicateur. C’est rapide, et cela signifie que chaque rapport, chaque règle et chaque agent qui lit cet objet doit désormais connaître l’indicateur.

Les échappatoires en texte libre. La structure migre dans les champs de notes. « Contrat n° … valable jusqu’au … » est saisi à la main selon un format fixe, parce que le modèle n’a nulle part où le mettre.

Les redéfinitions silencieuses. Une région est scindée en deux, et l’ancien nom couvre désormais un territoire plus petit. Les comparaisons d’une année sur l’autre comparent en silence des choses différentes.

La refonte en un seul bloc. Les changements sont mis de côté pour un grand projet « l’année prochaine ». En attendant, les contournements s’accumulent, et le projet devra tous les défaire.

Aucune trace du pourquoi. Personne ne se souvient pourquoi le type de client 7 existe ni si quelque chose l’utilise encore, donc personne n’ose le supprimer.

Des agents qui apprennent le contournement. Un agent qui travaille à partir du modèle actuel reproduit ses contournements fidèlement, et à grande échelle. Un humain a fini par apprendre à ignorer les commandes fantômes. Un agent ne le fera pas, sauf si le modèle le dit.

Faire évoluer le modèle comme on fait évoluer du code

Chaque changement est versionné. Chaque modification d’objets, de relations ou de règles a un auteur, une raison, une revue et un numéro de version, avec la même discipline que pour le code source. L’historique peut être lu plus tard par quelqu’un qui n’était pas là.

Ajouter d’abord, puis migrer, puis retirer. Introduisez le nouvel objet, le contrat de service, avec ses propres relations et règles. Basculez-y les enregistrements existants. Marquez l’ancien chemin comme obsolète, et ne le supprimez que lorsque plus rien n’en dépend. Ne redéfinissez jamais sur place une signification existante.

Utiliser des dates d’effet. La scission d’une région prend effet à une date donnée. L’historique conserve l’ancienne structure, les rapports savent laquelle s’appliquait à quel moment, et les comparaisons de part et d’autre de cette date sont faites en connaissance de cause.

Montrer l’impact avant l’approbation. Avant qu’un changement soit approuvé, listez tout ce qui dépend de ce qui est modifié : rapports, règles, agents, intégrations, documents. La personne qui approuve voit l’étendue des conséquences, pas seulement la différence.

Laisser les agents proposer, laisser les personnes approuver. Un agent peut repérer un contournement, par exemple que les commandes d’un certain type n’ont jamais d’articles, et proposer un nouvel objet pour le remplacer, preuves à l’appui. La personne responsable de cette partie de l’activité décide.

C’est ainsi qu’est conçue la couche Ontologie de Hurukan : des objets, des relations et des règles décrits et versionnés, enrichis à mesure que les agents étendent le système. Les propositions passent par les règles d’approbation de la couche Logique agentique, et chaque changement est audité comme effectué par une personne, un agent ou le système, comme décrit dans Sécurité et souveraineté. Elle est en construction. L’origine de la première version d’un tel modèle est traitée dans votre entreprise a déjà une ontologie.

Un test à faire dès aujourd’hui

Repérez les trois champs « type », « catégorie » ou « statut » les plus utilisés de votre système principal. Pour chacun :

1. Listez toutes les valeurs qu’il peut prendre.
2. Pour chaque valeur, retrouvez quand elle a été ajoutée, par qui et pourquoi.
3. Marquez les valeurs utilisées pour autre chose que ce que leur nom indique.

Cherchez ensuite dans vos enregistrements les champs de texte libre que les personnes remplissent selon un format fixe, comme « BC : … », « contrat n° … » ou « valable jusqu’au … ». Chaque format trouvé est un objet ou une relation que votre modèle n’a pas encore.

Ensemble, ces deux listes forment un carnet de changements que l’entreprise a déjà faits dans la réalité sans les avoir faits dans son modèle. Les traiter un changement versionné à la fois coûte moins cher que le grand projet de refonte qu’elles deviendraient sinon. Hurukan est conçu pour que ce carnet reste court.