Nouveau rôle, même constat : l’IA arrive après le ménage

Je change de rôle en septembre : je passe d’architecte de solutions à directeur technique chez HLC.

Ça m’oblige à regarder plus large. Une solution peut très bien fonctionner dans son équipe et créer une dépendance pénible pour toute l’organisation. Avec les projets d’IA, ce genre de problème ressort vite parce qu’un modèle demande des exemples cohérents et doit ensuite remettre son résultat dans le processus.

Le modèle voit les traces du processus

Prenons une demande de prix spéciale. Dans une équipe, le statut APPROUVÉ signifie que le gestionnaire a accepté la marge. Dans l’ERP, le même mot signifie seulement que le document peut être envoyé au prochain contrôle. Un modèle entraîné sur le statut sans connaître le système et l’étape mélange deux événements différents.

Je commencerais par écrire le processus comme une machine à états :

BROUILLON
   └─ soumettre → EN_ANALYSE
                    ├─ marge insuffisante → REVISION_REQUISE
                    ├─ information absente → EN_ATTENTE_CLIENT
                    └─ approuver → APPROUVEE
                                      ├─ expirer → EXPIREE
                                      └─ convertir → COMMANDE_CREEE

Chaque transition a un acteur, des données obligatoires et un événement horodaté. APPROUVEE n’est plus un texte libre : c’est l’état atteint après une transition précise, avec la version de la règle de marge et l’identité de la personne autorisée.

Le modèle peut alors prédire quelque chose de vérifiable, par exemple la probabilité qu’une demande EN_ANALYSE devienne une commande dans les 30 jours. La cible vient de la transition convertir, pas d’un statut dont le sens varie selon l’écran.

Faire circuler un événement plutôt qu’une deuxième saisie

Si le CRM et l’ERP ont besoin du même résultat, demander à une personne de le saisir deux fois crée deux sources de vérité. Je préférerais que le système responsable publie un événement avec un contrat explicite :

{
  "eventType": "SpecialPriceApproved",
  "eventVersion": 1,
  "requestId": "SPR-1842",
  "customerId": "C-938",
  "approvedAt": "2018-09-18T14:32:00Z",
  "ruleVersion": "margin-v3",
  "source": "pricing-service"
}

Le producteur garantit le sens de ces champs. Le consommateur garde l’identifiant de l’événement, applique la mise à jour et confirme son traitement. Si le réseau coupe après l’écriture mais avant l’accusé de réception, le message peut revenir. Une contrainte unique sur l’identifiant rend le traitement idempotent au lieu de créer deux approbations.

Le contrat doit évoluer sans casser les consommateurs. Ajouter un champ facultatif est généralement plus simple que renommer customerId ou changer son sens. Une nouvelle version peut rouler en parallèle pendant que les équipes migrent. Sans cette discipline, chaque projet d’IA finit par reconstruire une intégration différente avec les mêmes ambiguïtés.

Nommer la source et la responsabilité

Une nomenclature commune ne veut pas dire recopier toutes les données dans une seule base. Pour chaque concept, il faut plutôt savoir :

  1. quel système crée l’identifiant de référence;
  2. quel service peut modifier l’état;
  3. quelles copies sont des projections en lecture;
  4. comment une correction est propagée;
  5. qui tranche lorsque deux définitions se contredisent.

L’ERP peut rester la source de vérité de la commande, le CRM celle du contact et un entrepôt une copie analytique. Le modèle reçoit un snapshot daté de ces sources. Il ne doit pas écrire directement dans leurs tables pour contourner les règles; sa recommandation revient par une API ou une transition prévue.

Les cas qui cassent le processus deviennent alors visibles. Un événement peut rester dans une file d’erreur. Un identifiant client peut manquer de correspondance. Une demande peut être corrigée après son approbation. Il faut des métriques sur l’âge des messages, une file de reprise, un écran pour résoudre les correspondances et un journal capable de rejouer l’état.

Je ne blâme pas automatiquement l’ancien système. Il répondait peut-être très bien au besoin de départ. Mais lui demander des données cohérentes pour une décision qui n’existait pas exige une vraie modification, pas une jointure ajoutée à la fin.

Dans mon nouveau rôle, je prioriserais parfois ce travail moins visible avant le modèle : définir les états, enlever une double saisie, publier un contrat et nommer un responsable. Une fois ce chemin fiable, plusieurs projets peuvent utiliser la même donnée sans recommencer le ménage. C’est une meilleure fondation qu’une autre démo branchée directement sur trois tables qu’on n’ose plus changer.