Brancher une IA sur 31 logiciels métier : le jour où une API a menti

« Est-ce que ça se branche sur notre logiciel ? »

En rendez-vous, la question arrive toujours sous la même forme : « Est-ce que ça se branche sur notre logiciel ? » Le dirigeant a en tête son outil métier, celui que toute l’entreprise utilise depuis dix ans, celui que personne d’autre ne connaît vraiment. Il s’attend, un peu, à ce que je lui dise non.

La réponse est presque toujours oui. La plupart des logiciels métier, même les moins connus, exposent une API : une porte par laquelle un programme extérieur peut lire et écrire des données sans passer par l’écran. Le branchement en lui-même n’est presque jamais l’obstacle. Ce qui coûte, c’est ce qui se passe le jour où ce branchement s’arrête de fonctionner sans le dire.

Ce qu’il y a derrière le mot connecteur

Un connecteur a quatre tâches. S’authentifier auprès du logiciel, lire des données, en écrire quand un agent IA doit agir, et dire clairement quand il ne fonctionne plus. Cette dernière tâche, la plus simple sur le papier, est celle que je vois le plus souvent bâclée.

Livia, le produit que je construis, branche une IA sur les outils qu’une entreprise utilise déjà. Son registre de connecteurs couvre aujourd’hui 31 logiciels métier : des outils de gestion commerciale comme HubSpot ou Salesforce, des plateformes de formation comme Moodle, Hyperplanning, Dendreo ou Yparéo, des outils de gestion des dossiers de formation comme Wedof ou Digiforma, et d’autres encore.

Trente et un logiciels, ça veut dire trente et une façons différentes de s’authentifier, trente et un formats de réponse, et surtout trente et une façons de tomber en panne. La plupart tombent en panne franchement. Moodle a sa propre méthode.

Le jour où une API a menti

Un matin, le connecteur Moodle cesse de ramener des données. Aucune alerte ne part. Il continue de répondre, le code HTTP est 200, le signal que tout serveur envoie d’ordinaire quand une requête a réussi.

Un code HTTP est le signal standard qu’échangent deux programmes sur le web pour dire si une requête a réussi, avant même que quiconque lise le contenu de la réponse. 200 veut dire : « j’ai bien reçu ta demande, et je te réponds ». Un branchement qui s’arrête à ce code conclut, la plupart du temps à raison, que tout va bien.

Sauf que Moodle, quand le jeton d’accès est invalide, renvoie quand même un 200, et écrit l’erreur dans le corps de la réponse, le texte que la plupart des connecteurs ne lisent jamais. J’ai cherché pourquoi un connecteur donné pour fonctionnel ne ramenait plus rien, avant de trouver l’erreur, écrite noir sur blanc, à un endroit que rien n’allait lire.

Une API absente casse tout de suite, et ça se voit. Une API qui répond 200 en cachant son erreur dans le texte casse en silence. Le logiciel métier a l’air branché. Le connecteur a l’air vivant. Pendant ce temps, plus aucune donnée ne remonte.

Pourquoi une panne silencieuse coûte plus cher

Une API qui n’existe pas se voit dès le devis : le prestataire le dit, le prix s’ajuste, tout le monde sait à quoi s’attendre. Une API qui ment ne coûte rien sur le devis. Elle coûte après, en production, le jour où plus personne ne sait si les chiffres affichés sont encore à jour. Les postes de coût d’un assistant branché sur un logiciel métier, je les détaille dans cet article sur ce que coûte réellement l’usage.

Une fois le problème trouvé, la réparation va vite. Le client qui a appelé le lundi, lui, ne demande pas comment fonctionne un code HTTP : il retient qu’un rendez-vous a été perdu. Pour le dirigeant, cette panne de trois jours se traduit par un appel mécontent et une visite à reprogrammer en urgence.

Surveiller au lieu d’attendre l’appel du client

Livia interroge la santé de chaque connecteur toute seule, à intervalles réguliers, sans attendre qu’un utilisateur tombe sur l’erreur en premier. Un connecteur qui ment fait partie des façons dont un agent IA dérape en production, que je détaille dans cet article sur ce qui casse un agent IA en production.

Le balayage interroge les fournisseurs en parallèle, cinq à la fois : les interroger l’un après l’autre prendrait de longues secondes sur un registre de 31 logiciels métier. Chaque fournisseur a 8 secondes au maximum pour répondre. Passé ce délai, le connecteur est déclaré en panne, même s’il finit parfois par répondre une seconde plus tard.

Un délai maximum court est un choix de fiabilité. Une page de surveillance qui attend indéfiniment une réponse devient elle-même inutilisable, et un fournisseur trop lent à répondre pose, pour l’utilisateur qui attend, exactement le même problème qu’un fournisseur tombé.

Les cinq questions à poser avant de signer

Avant de signer un projet d’intégration IA, cinq questions suffisent à savoir si le prestataire a déjà pensé à la panne autant qu’au branchement. Elles se posent au prestataire, et aussi à l’éditeur du logiciel métier : lui seul connaît vraiment son API. La dernière, sur qui paie la remise en état, rejoint ce que je détaille dans cet article sur les postes de coût d’un projet IA.

1. Comment l’assistant s’authentifie-t-il auprès du logiciel, et combien de temps ce jeton reste-t-il valide avant de devoir être renouvelé ?
2. Que renvoie l’API quand une opération échoue : un code HTTP différent de 200, ou une erreur cachée dans le corps de la réponse, comme chez Moodle ?
3. Qui est prévenu quand un connecteur tombe, et combien de temps s’écoule avant que quelqu’un le sache ?
4. Que se passe-t-il quand l’éditeur du logiciel change son API, ajoute un champ, retire un paramètre, ou impose une nouvelle version ?
5. Qui paie la remise en état d’un connecteur cassé par un changement que ni vous ni le prestataire n’avez demandé ?

Les accès précis à demander à l’éditeur d’un logiciel immobilier comme Apimo ou Hektor, je les détaille dans ce décryptage sur les intégrations IA en agence immobilière. La grille par où commencer reprend ces cinq questions avant même de demander un devis.