La plupart des organisations de taille moyenne ou grande exploitent plusieurs systèmes centraux, achetés à des dates différentes auprès de fournisseurs différents. Un ERP contient les données financières et d'approvisionnement, un CRM les échanges avec les clients, et dans le secteur de la santé un système d'information hospitalier, le plus souvent appelé HIS, les dossiers patients, les prescriptions et la facturation. Les relier est rarement la partie la plus visible d'un projet, et pourtant c'est souvent ce qui décide de sa livraison dans les délais. Cet article présente les problèmes les plus fréquents et les pratiques qui permettent de les réduire.

Pourquoi les projets d'intégration dérapent

Les estimations d'intégration sont souvent optimistes, car le travail reste caché tant qu'il n'a pas commencé. Quatre causes reviennent régulièrement.

  • Champs non documentés. Une table comporte une colonne utilisée dans un but que personne ne se rappelle, et le seul moyen d'en comprendre le sens est d'interroger la personne qui l'a configurée il y a des années.
  • Deux sources de vérité. Les données clients ou produits existent dans les deux systèmes, et les deux copies divergent. Quelqu'un doit décider laquelle prévaut et selon quelles règles.
  • Attentes différentes sur le traitement par lots et le temps réel. Un utilisateur métier demande des données à jour, le système source ne sait exporter que la nuit, et l'écart est découvert tard.
  • Interfaces contrôlées par l'éditeur. L'éditeur décide des interfaces disponibles, de leur coût et de leur évolution, et l'équipe d'intégration dépend donc de calendriers extérieurs.

Options d'interface

Le choix de l'interface dépend de ce que le système source prend en charge et du niveau de fraîcheur exigé pour les données. Les services web REST et SOAP sont la voie la plus courante pour les ERP et CRM modernes. Ils permettent un échange de type requête et réponse et se supervisent facilement, mais ils supposent que le système source expose les bonnes opérations.

L'échange de fichiers reste très répandu. Les exports CSV ou XML planifiés sont simples et robustes, et conviennent aux rapports et aux synchronisations nocturnes. Les files de messages découplent l'émetteur du destinataire, de sorte qu'un des deux côtés peut être indisponible un moment sans perte de données. Elles conviennent aux flux pilotés par les événements, où l'ordre et la livraison comptent.

Pour les données de santé, les messages HL7 version 2 restent courants pour les admissions, les prescriptions et les résultats, et FHIR est de plus en plus utilisé pour les échanges par API. Ces standards réduisent le travail de correspondance sur mesure, même si les profils et extensions locaux doivent encore être convenus avec chaque éditeur.

Correspondance des données et qualité des données

La correspondance des données est le cœur du travail. Pour chaque champ, l'équipe consigne la source, la cible, la transformation et la règle en cas de conflit. Les listes de codes, les unités, les formats de date, les encodages de caractères et les identifiants demandent une attention particulière, car un patient, un client ou un produit peut porter un identifiant différent dans chaque système.

Les problèmes de qualité des données apparaissent généralement à cette étape : doublons, valeurs obligatoires manquantes, champs de texte libre utilisés comme codes. Il vaut mieux les corriger à la source, avec des règles de nettoyage validées par les responsables des données, plutôt que de les contourner dans l'interface où ils deviennent invisibles.

Sécurité et traçabilité

Les comptes d'intégration doivent respecter le principe du moindre privilège, avec un accès limité aux opérations dont l'interface a besoin. Chaque appel qui lit ou modifie des données personnelles doit être journalisé, avec qui, quoi et quand, et les journaux doivent être protégés et conservés conformément à la politique en vigueur.

Les données personnelles relèvent de la KVKK en Türkiye et du RGPD dans l'UE. Pour les données de santé, les exigences sont plus strictes. La conception de l'intégration doit définir quelles données sont transférées, dans quel but, comment elles sont protégées en transit et au repos, et pendant combien de temps les copies sont conservées.

Tests et retour arrière

Les interfaces doivent être testées avec des données réalistes, y compris des cas limites comme les noms longs, les caractères spéciaux, les commandes annulées et les résultats corrigés. Des environnements de test qui reproduisent les versions de production des deux systèmes sont précieux, car le comportement diffère souvent d'une version à l'autre. Un plan de bascule doit préciser l'ordre des étapes, les vérifications après chaque étape et les conditions dans lesquelles l'équipe revient à l'état précédent.

Exploitation après la mise en service

Une interface est un service en production. Elle nécessite une supervision des échecs et des retards, une file d'erreurs où les messages rejetés peuvent être examinés et rejoués, et des alertes qui parviennent à une personne désignée. Chaque interface doit avoir un responsable côté métier et un côté technique, avec une documentation qui décrit son objet, sa planification, sa correspondance de données et ses limites connues. Sans cela, les petites défaillances s'accumulent jusqu'à ce que les données des deux systèmes ne concordent plus.