Interopérabilité chez un bailleur social : par où commencer

Tous les bailleurs sociaux que nous rencontrons ont le même diagnostic et la même hésitation. Le diagnostic : « nos outils ne se parlent pas ». L’hésitation : par quel bout prendre le sujet, sachant que le dernier projet d’intégration a coûté cher et n’a relié que deux applications.

La bonne nouvelle, c’est que l’ordre des opérations compte plus que la technologie choisie. Voici celui que nous recommandons.

1. Choisir le flux qui fait le plus mal, pas le plus simple

La tentation est de commencer par un flux facile, pour se rassurer. C’est une erreur. Un flux facile produit une démonstration réussie dont personne ne mesure la valeur, et le projet s’arrête au premier arbitrage budgétaire.

Prenez plutôt le flux que vos équipes citent spontanément quand on leur demande ce qui leur gâche la semaine. Dans la plupart des organismes, c’est l’un des trois suivants :

• l’attribution : une décision prise en commission qui doit redescendre dans l’outil de gestion locative et dans l’ERP ;
• la gestion locative : les entrées, les sorties, les changements de situation, qui alimentent une demi-douzaine d’outils ;
• les interventions : une demande qui naît dans un canal et doit arriver chez le bon prestataire, avec le bon marché.

Le flux le plus douloureux a un autre mérite : il est déjà documenté, parce que quelqu’un a déjà écrit la procédure manuelle qui le compense.

2. Garder un oracle tant qu’on en a un

Si vous avez aujourd’hui un robot, un traitement d’intégration ou un export programmé qui fait à peu près le travail, ne l’éteignez pas en même temps que vous branchez le nouveau flux. Faites tourner les deux en parallèle et comparez le différentiel.

C’est le meilleur cahier de recette qui existe, et il est gratuit : chaque écart entre l’ancien et le nouveau est soit un bug du nouveau, soit une règle métier que personne n’avait écrite et que l’ancien appliquait sans le dire. Les deux sont précieux à découvrir.

Cet oracle a une date de péremption : le jour où l’ancien traitement s’arrêtera, vous n’aurez plus de point de comparaison. Profitez-en tant qu’il tourne.

3. Interdire dès le premier jour le code spécifique à un organisme

C’est la règle qui décide si vous aurez une plateforme ou une collection de tuyaux.

Chaque bailleur a ses particularités : une nomenclature maison, un champ détourné de son usage, une règle de gestion héritée d’une fusion. La question n’est pas de savoir si ces particularités existent, elles existent toujours, mais où elles vivent.

Si elles vivent dans le code, chaque nouvel organisme est un développement, chaque montée de version est un risque, et la dixième connexion coûte aussi cher que la première. Si elles vivent dans un descripteur, un paramètre ou un remplacement déclaré, la dixième connexion est du paramétrage.

La règle tient en une phrase : si brancher un organisme sur une combinaison déjà connue demande du code, la conception est fausse. Elle est exigeante, et elle est la seule qui permette de tenir un parc de connexions dans la durée.

Les trois pièges classiques

Vouloir un référentiel central avant de faire circuler quoi que ce soit. L’idée de construire d’abord une base pivot qui contiendrait « la vérité » est séduisante et, dans notre expérience, mortelle. Elle déplace le problème sans le résoudre : il faut maintenant synchroniser le pivot, arbitrer les conflits, et personne n’a de flux qui tourne au bout d’un an. Faites circuler d’abord ; la vérité partagée viendra après, et elle viendra d’un entrepôt de données, pas d’un pivot opérationnel.

Écrire dans la base de l’ERP. C’est techniquement possible et commercialement fatal. Vous perdez le support de votre éditeur, vous contournez ses contrôles de cohérence, et vous héritez d’une dette que personne ne saura porter dans trois ans. La lecture SQL est légitime ; l’écriture passe par les moyens prévus par l’éditeur.

**Confondre « ça marche » et « on le sait ». ** Un flux automatique qui tombe silencieusement est pire qu’un traitement manuel, parce que la confiance qu’il inspire survit à sa panne. Tout flux doit répondre en permanence à trois questions : qu’est-ce qui est parti, qu’est-ce qui a échoué, depuis quand. Si l’outil ne répond pas à ces questions, il n’est pas terminé.

Et ensuite

Un premier flux en production change la conversation dans un organisme. On passe de « est-ce que c’est possible » à « qu’est-ce qu’on branche ensuite ». À ce moment-là seulement, les sujets suivants deviennent abordables : un catalogue de services partagé, un entrepôt qui conserve l’histoire, des tableaux de bord construits sur une source unique.

L’interopérabilité n’est pas une fin en soi. C’est la condition d’à peu près tout le reste.

---

Vous voulez en parler pour votre organisme ? Écrivez-nous à contact@oxli.io ou demandez une démonstration.