Les institutions publiques et les opérateurs manquent rarement de systèmes. Ce qui leur manque est ailleurs : un chemin cohérent que les données parcourent entre eux. Un registre national répond par une API, l’ERP financier par une tout autre, les automates SCADA parlent un protocole industriel, et l’archive documentaire garde son propre format. Le résultat : des ressaisies manuelles, des données qui divergent et des processus qui se bloquent sur un seul tableur.
D’après notre expérience, le problème n’est pas une technologie en particulier mais la réunion de mondes qui n’ont jamais été conçus pour coopérer. Même sans pointer ici une étude de cas nommée, nous fournissons les personnes qui relient ces systèmes au quotidien : ingénieurs d’intégration, architectes et spécialistes qui comprennent les infrastructures critiques. Nous construisons la couche qui réunit registres, ERP, SCADA et archives en un flux de données prévisible.
Pourquoi les intégrations du secteur public et des utilities sont-elles si difficiles ?
Parce qu’une institution est généralement faite de couches technologiques d’époques différentes que personne ne peut éteindre. Un système bâti il y a quinze ans fait tourner un processus critique et fonctionne toujours : il reste donc, et les nouvelles solutions s’accumulent à côté. Avec le temps, on obtient une architecture où chaque composant mène sa propre vie.
Trois facteurs se conjuguent :
- les silos de données - chaque service a son système et sa version de la vérité sur le même citoyen ou le même point de comptage,
- le legacy - des applications anciennes sans API moderne, souvent non documentées et dont l’auteur n’est plus là,
- la sécurité et la réglementation - données personnelles, infrastructures critiques et règles qui interdisent d’« exposer simplement un endpoint au monde ».
C’est pourquoi on ne peut pas traiter une intégration institutionnelle comme un projet ordinaire de branchement de deux applications. Il faut concilier l’ancien et le nouveau sans interrompre des services dont les gens dépendent chaque jour.
À quoi ressemble l’intégration avec les registres nationaux ?
Les registres nationaux forment une catégorie à part. Ils imposent leurs propres standards d’échange, leurs procédures d’accès et des fenêtres de maintenance sur lesquelles vous n’avez aucune prise. L’intégration des registres nationaux consiste donc moins à écrire un client d’API qu’à l’envelopper pour que le reste de vos systèmes ne sente jamais qu’un service tiers, parfois capricieux, se trouve en face.
En pratique, nous construisons une couche de médiation qui traduit les formats des registres dans le modèle de données de l’institution, met les réponses en cache, gère l’authentification et les signatures, et journalise chaque requête pour l’audit. Lorsque le registre est indisponible, le système ne s’effondre pas ; il met les requêtes en file et les rejoue selon des règles convenues. L’agent ou le processus interne obtient une interface stable au lieu d’une connexion brute au monde extérieur.
Comment relier l’ERP et les systèmes financiers au reste de l’organisation ?
L’ERP est souvent le coeur d’une institution, et pourtant il est rarement ouvert. Nous le relions à la gestion documentaire, aux systèmes métier et aux registres pour que les données financières cessent de voyager à la main et circulent par un canal contrôlé.
Nous le livrons le plus souvent par :
- une intégration par API et par bus (ESB, API gateway) plutôt que par des liens point à point fragiles,
- une synchronisation des données de référence (tiers, nomenclatures, plan comptable) entre l’ERP et les systèmes métier,
- une automatisation des flux de factures et de paiements en préservant le circuit de validation et la piste d’audit,
- un reporting et des déclarations réglementaires alimentés par les données de plusieurs systèmes à la fois.
La cohérence est ici la clé : si le même tiers porte trois identifiants différents dans trois systèmes, aucune automatisation ne tiendra. Avant de relier quoi que ce soit, nous mettons donc le modèle de données en ordre.
Comment intégrer le SCADA et le comptage sans perturber le monde OT ?
Chez un opérateur, la frontière la plus difficile passe entre l’IT et l’OT, entre le monde des applications métier et celui de la conduite de processus. SCADA, automates et systèmes de comptage vivent sur un réseau industriel où la continuité de fonctionnement et la sûreté priment sur le confort d’intégration.
L’intégration SCADA exige de la prudence, car une erreur ici ne signifie pas un message faux sur un écran mais un effet réel sur l’infrastructure. Nous collectons donc les données OT par des passerelles dédiées et des protocoles industriels (comme OPC UA, Modbus, MQTT), les mettons en tampon, et n’exposons qu’ensuite le flux nettoyé aux applications métier, à l’analytique ou à la facturation. Nous faisons circuler le trafic dans un seul sens contrôlé, en gardant les réseaux séparés, pour que le côté métier puisse lire la télémétrie sans jamais acquérir la capacité de toucher à la conduite. Cette séparation des responsabilités est un fondement, pas une option.
Comment intégrer la gestion documentaire et les archives dans un seul flux ?
La gestion électronique des documents, les référentiels et les archives numériques sont l’endroit où un processus se bloque le plus souvent. Nous les relions aux registres et à l’ERP pour qu’un document soit créé, circule et atteigne l’archive sans export ni import manuels.
Dans ce domaine, nous procédons généralement ainsi :
- relier la gestion documentaire aux systèmes métier, pour que le dossier et le document forment un flux unique plutôt que deux flux séparés,
- automatiser les métadonnées et la classification à partir de données déjà détenues dans d’autres systèmes,
- brancher l’archive conformément aux exigences de conservation et aux formats de préservation à long terme.
Un flux documentaire bien relié cesse d’être un goulot d’étranglement et devient une étape naturelle du processus, où une donnée saisie une fois n’a plus jamais à être retapée.
Comment rendre les intégrations fiables et sûres ?
Une intégration institutionnelle doit continuer à fonctionner même quand l’un des systèmes se tait un instant. Nous la concevons donc tolérante aux pannes, et non comme une chaîne qui casse au premier maillon rompu.
Nous l’appuyons sur quelques piliers :
- des files de messages (comme Kafka, RabbitMQ) qui découplent les systèmes et absorbent les pics de trafic,
- des relances et l’idempotence, pour que répéter une requête ne duplique jamais une opération,
- le chiffrement en transit et au repos, ainsi qu’un contrôle d’accès aligné sur les exigences de l’institution,
- la supervision et une piste d’audit complète montrant qui a échangé quelles données et quand.
Avec cette architecture, un registre momentanément muet ou un ERP sous charge devient un événement que le système traite tout seul, et non un incident qui appelle une réparation manuelle à l’aube.
Quelles compétences apportons-nous à un projet d’intégration ?
Pour ce type de projets, nous construisons l’équipe autour de l’architecture précise, pas « au cas où ». Nous pourvoyons le plus souvent les rôles :
- d’un architecte d’intégration qui conçoit l’ensemble du flux et fixe les standards,
- d’ingénieurs backend et intégration (Java, .NET, Python) qui construisent connecteurs, API et bus,
- de spécialistes DevOps et sécurité responsables des files, de l’infrastructure et du durcissement,
- de spécialistes OT / industriels partout où le SCADA et le comptage entrent en jeu.
Nous avons une expérience réelle des projets pour l’administration publique et de l’intégration de systèmes, ainsi que des infrastructures critiques : nous comprenons donc à la fois la rigueur réglementaire et les réalités du travail avec le monde OT. Nous ne l’adossons pas à un déploiement unique, car il s’agit ici de la compétence que nous apportons dans l’équipe du client.
Comment procédons-nous chez RITS ?
Nous travaillons en partenaire nearshore depuis la Pologne qui ajoute les compétences manquantes à l’équipe d’une institution ou d’un opérateur. Sur les projets d’intégration, cela signifie que nous :
- pourvoyons les rôles d’architecte et d’ingénieurs d’intégration formés au travail avec le legacy et la rigueur réglementaire,
- vérifions les compétences avant le démarrage et adaptons l’équipe à l’architecture et aux protocoles concernés,
- rejoignons le rythme existant du client, ses revues de code et ses procédures de sécurité sans longue montée en charge,
- faisons le pont entre IT et OT dans le respect de la séparation des réseaux et des exigences des infrastructures critiques.
Le plus souvent, nous procédons en renfort d’équipe ou en équipe dédiée et, là où une institution bâtit une nouvelle couche d’intégration depuis les fondations, en logiciel sur mesure créé par notre équipe.
Par où commencer pour intégrer les systèmes d’une institution ?
Commencez par le flux le plus douloureux - par exemple l’endroit où quelqu’un ressaisit chaque jour des données entre un registre et l’ERP. Décrire ce seul parcours de bout en bout révèle les connecteurs, la couche de sécurité et les rôles dont vous avez réellement besoin, avant de vous attaquer à toute l’architecture. Nous avons traité les différences entre modèles de collaboration dans notre article sur les modèles de collaboration IT.
Vous reliez registres nationaux, ERP, SCADA ou archives dans une même institution ? Parlons-en - nous adapterons une équipe et une architecture à votre parc de systèmes.