L'interopérabilité ne s'obtient pas en l'inscrivant au cahier des charges
Deux systèmes n'échangent que si quelqu'un détient le mandat d'arbitrer le format, le rythme et la responsabilité de la donnée. Ce mandat s'attribue avant le développement.
L’exigence est présente dans presque toutes les consultations publiques : le système doit être interopérable avec les systèmes existants. Elle est rarement suivie d’une description de ce que cela signifie, et elle produit alors une interface technique que personne n’utilise.
Une interface n’est pas un échange
Livrer une interface de programmation documentée est une prestation technique. Elle s’achève à la recette. Faire circuler une donnée entre deux autorités est un arrangement durable entre deux organisations qui n’ont ni les mêmes procédures, ni le même calendrier, ni le même responsable.
Trois questions décident de l’issue, et aucune n’est technique.
Qui fait foi ? Lorsque deux systèmes portent une information divergente sur la même personne, l’un des deux prévaut. Cette règle s’écrit une fois pour toutes, ou elle se rejoue à chaque incident.
À quel rythme ? Une donnée transmise chaque nuit et une donnée transmise à l’instant de sa modification n’appellent pas la même architecture et ne coûtent pas le même prix. Le rythme se déduit de l’usage : un contrôle au poste frontière ne tolère pas le décalage qu’une statistique mensuelle tolère sans difficulté.
Qui répond de l’erreur ? Une donnée fausse transmise par le système A et exploitée par le système B produit une décision fausse. La responsabilité se répartit à l’avance, faute de quoi elle se discute au moment où une décision doit être corrigée.
Le contrat d’interface
Ces réponses tiennent dans un document court, signé par les deux autorités, qui énonce le format, le rythme, le point de contact de chaque partie, la conduite à tenir en cas d’indisponibilité et la durée de conservation des échanges. Il ne relève pas du marché de développement, il le précède.
Un projet qui commence à développer avant que ce document existe développe contre une hypothèse. L’hypothèse se révèle fausse à l’intégration, c’est-à-dire au moment du projet où une correction coûte le plus cher.
Le format n’est pas le sujet
Le choix d’un standard d’échange occupe une place dans les débats sans rapport avec son influence sur le résultat. Un format documenté, stable et lisible par un humain suffit dans la quasi-totalité des cas. Ce qui échoue n’est pas le format : c’est l’absence de règle sur ce qui se passe quand le système d’en face ne répond pas pendant six heures, ou quand un enregistrement transmis hier a été supprimé depuis.
Ces deux situations surviennent. Une architecture qui ne les a pas traitées les traitera en production, sous contrainte de temps, par une décision prise dans l’urgence.
Le cas des systèmes qu’on ne maîtrise pas
Une administration doit fréquemment échanger avec un système dont elle n’est ni propriétaire ni exploitante, et dont elle n’obtiendra aucune modification. La solution n’est pas d’attendre. Elle consiste à poser un composant de médiation dont elle a la maîtrise, qui absorbe les particularités du système distant et présente une interface stable au reste du dispositif.
Ce composant a un coût et une valeur : il isole l’organisation des changements décidés ailleurs, ce qui est précisément ce qu’elle ne peut pas obtenir par contrat.
Ce qu’il faut exiger
Un contrat d’interface signé avant le démarrage du développement, portant les trois réponses. Une procédure écrite de reprise après indisponibilité du système distant. Un journal des échanges conservé et consultable. Et un jeu de données d’essai représentatif, fourni par le détenteur du système distant, sans lequel aucune intégration ne se vérifie avant la mise en service.
