Une automatisation n'est pas un meuble : c'est un organisme branché sur des systèmes qui bougent sans vous prévenir. Un fournisseur modifie le format d'une réponse. Un modèle est mis à jour et devient plus prudent, donc moins tranchant. Un commercial change une règle de remise et personne ne pense à le dire. Trois mois plus tard, le process fonctionne toujours, mais moins bien, et personne ne sait depuis quand.

Les cinq questions à poser, une par une

  • Qui intervient quand une interface change ? Une personne nommée, un délai d'intervention annoncé, et un moyen de la joindre.
  • Qui surveille, et sur quoi ? Une supervision utile ne se contente pas de vérifier que le service répond : elle vérifie que le résultat est encore bon.
  • Qui corrige les erreurs, et sous quel délai ? Distinguer l'incident bloquant de la dérive lente, qui n'a pas le même traitement.
  • Que se passe-t-il si le modèle change de comportement ? Il faut une version figée, un jeu d'exemples de référence, et une comparaison avant bascule.
  • Combien coûte tout cela par an ? Un chiffre annoncé avant la signature, pas un devis découvert au premier incident.

Surveiller le résultat, pas seulement le service

La supervision classique répond à la question « est-ce que ça tourne ». Ce n'est pas suffisant : une automatisation peut tourner parfaitement et produire des résultats de moins en moins bons. Nous surveillons donc aussi le fond : le taux de propositions corrigées par un humain, la part de cas passés en incertain, le coût moyen par exécution, et les délais de bout en bout.

Quand l'un de ces indicateurs dérive, il y a un signal avant l'incident. C'est toute la différence entre corriger une automatisation et la découvrir cassée par un client mécontent.

Une automatisation ne tombe presque jamais d'un coup. Elle se dégrade, et le silence passe pour de la stabilité.

Le changement de modèle

C'est le risque propre aux projets d'IA, et il est mal connu. Un modèle mis à jour n'est pas le même produit : le style change, la prudence change, le format de sortie peut changer. Trois précautions suffisent : ne jamais laisser un process pointer sur une version flottante, garder un jeu d'exemples avec les réponses attendues, et rejouer ce jeu avant toute bascule. Si le prestataire n'a pas ces exemples de référence, il ne peut pas savoir ce qu'une mise à jour a changé chez vous.

Reprendre la main

C'est le point qui protège l'entreprise sur le long terme. Il tient à quatre conditions : le code et les consignes sont chez vous, les comptes des services utilisés sont à vous, la documentation existe et est lisible par quelqu'un d'autre, et une passation est prévue au contrat. Un prestataire qui accepte ces quatre conditions n'a pas peur d'être remplacé, ce qui est en général un bon signe sur le reste.

Nous détaillons ce sujet dans l'article sur la propriété, et notre offre de pilotage sur la page Orchestrateur IA décrit précisément qui fait quoi une fois le projet livré.

Notre position

Nous ne vendons pas une livraison suivie d'un silence. La supervision, la correction et l'adaptation font partie du service, avec un coût annoncé, parce que c'est la seule façon honnête de présenter une automatisation : ce n'est pas un achat, c'est une exploitation.