Bailleurs sociaux : modernisez votre système d’information sans changer d’ERP

Le secteur du logement social est en pleine mutation, pris en étau entre deux impératifs. D’un côté, une consolidation massive des organismes (fusions OPH/ESH sous l’impulsion de la loi ELAN) et des exigences réglementaires accrues (DPE, passoires thermiques…). De l’autre, la nécessité impérieuse de digitaliser la relation client pour offrir de nouveaux services aux locataires. Pourtant, au cœur du Système d’Information (SI) des bailleurs sociaux, l’ERP historique agit souvent comme un frein puissant à cette modernisation. Dès lors, comment concilier un existant rigide, garant de la gestion comptable et locative, avec des besoins vitaux d’agilité ?

Davy Hassenboehler, Directeur Avant-Vente chez Blueway, nous partage ses solutions pour adresser les défis d’interopérabilité et de gestion des données propres aux bailleurs sociaux.

Pour commencer, peux-tu nous brosser un portrait rapide du paysage SI chez les bailleurs sociaux aujourd’hui ?

L’hétérogénéité actuelle du paysage résulte à la fois de son histoire et des nombreux regroupements qui ont eu lieu. Nous sommes en effet face à des organismes qui ont subi de nombreuses fusions et consolidations ces dernières années. Le Système d’Information se retrouve donc souvent à devoir gérer l’héritage (« legacy ») de plusieurs structures, avec des pratiques métiers divergentes et des outils différents qui cohabitent parfois difficilement.

“Au centre de cet écosystème complexe, on trouve toujours un ERP « roi », censé tout faire et tout centraliser. Mais cet outil monolithique est aujourd’hui totalement débordé par la demande de nouveaux usages : CRM pour la relation client, mobilité pour les gardiens, extranets locataires, BIM pour la gestion technique…”

Bien que la pression pour la modernisation et l’ouverture du SI soit forte, l’ampleur de la dette technique entrave significativement cette progression, induisant des évolutions lentes et onéreuses.

Les ERP des bailleurs sociaux sont souvent décrits comme « fermés ». Concrètement, qu’est-ce que cela implique ?

Quand on dit « fermé », ce n’est pas qu’une image, c’est une réalité technique quotidienne et frustrante pour les DSI. Ces solutions historiques reposent souvent sur des architectures anciennes, parfois héritées de l’époque du mainframe ou de l’AS400, qui n’ont pas été conçues pour l’ère du web et de l’ouverture. Concrètement, cela signifie plusieurs obstacles majeurs à surmonter :

• Une absence quasi-totale d’API natives et documentées : Contrairement aux solutions SaaS modernes, ces ERP n’offrent pas ou peu de connecteurs standards (API REST/JSON) pour dialoguer en temps réel avec le monde extérieur.

• Des modèles de données rigides et complexes : Le schéma de base de données est souvent complexe. Ajouter un simple champ pour suivre une nouvelle réglementation (par exemple un nouveau type de diagnostic énergétique ou une variable sociale spécifique) relève souvent du parcours du combattant, car les champs génériques ne permettent pas la mise en place des règles de gestion nécessaire.

• Un accès aux données complexe et risqué : Pour extraire de l’information, les équipes IT doivent souvent contourner l’interface pour aller requêter directement dans la base de données (DB2, Oracle…), avec tous les risques que cela comporte en termes de maintenance et de performance.

“L’ERP cherche structurellement à garder la mainmise sur toute la donnée, ce qui crée un effet « silo » très fort et un phénomène de « vendor lock-in » (verrouillage propriétaire) dont il est difficile de s’extraire”.

Le SI des bailleurs sociaux est composé de multiples outils (CRM, portail locataires, etc.). Comment communiquent-ils avec l’ERP aujourd’hui ?

Pour pallier les manques fonctionnels de l’ERP, les bailleurs sociaux ont massivement investi dans des outils « Best of Breed » (le meilleur CRM du marché, la meilleure solution de gestion technique de patrimoine, des portails web modernes). Mais la “rediscussion” avec le cœur du système reste archaïque. Nous voyons en effet beaucoup de développements « point à point » : on développe une interface spécifique pour connecter le Portail Locataire à l’ERP, une autre interface ad-hoc pour le CRM, une troisième pour l’état des lieux sur tablette. Cela crée un véritable « plat de spaghettis » indigeste.

“Le danger est donc systémique : les interfaces et les traitements se font de manière empirique sans consolidation et avec une difficulté de suivi des traitements”.

Résultat : on trouve souvent des données locataires incohérentes, avec une version dans le CRM et une autre dans l’ERP, car la synchronisation a échoué silencieusement. Cela dégrade la confiance des utilisateurs dans le système.

Voit-on encore beaucoup de traitements « batch », par échange de fichiers plats au sein des bailleurs sociaux ?

Absolument, c’est malheureusement encore la norme majoritaire dans le secteur. Faute de pouvoir dialoguer en temps réel via des API, les bailleurs sociaux fonctionnent beaucoup par échange de fichiers plats (CSV, fichiers positionnels à longueur fixe) qui sont générés et déposés sur un serveur FTP durant la nuit. Le problème majeur, c’est la latence et le manque de réactivité. Voici un scénario classique : un gestionnaire met à jour une information critique dans l’ERP le lundi matin (par exemple un changement de situation familiale). Le traitement batch ne tourne que la nuit suivante. L’outil tiers (CRM ou Portail) ne récupère et n’intègre l’info que le mardi midi… si tout va bien. Il peut donc s’écouler 24 à 48h (voire 72h le week-end) avant que l’information soit unifiée partout.

“À l’heure du numérique “temps réel” et des standards imposés par les géants du web, expliquer à un locataire que son paiement en ligne ou son changement de RIB ne sera visible que dans plusieurs jours sur son compte client, ce n’est plus acceptable et génère des appels inutiles au centre de contact”.

Pourquoi les gestionnaires de terrain préfèrent-ils Excel à l’outil cœur de métier ?

Le gestionnaire de terrain, ou le gardien, est pragmatique. Il a besoin de gérer la réalité : une panne d’ascenseur, un diagnostic plomb, une entrée dans les lieux. Souvent, l’ERP est trop rigide pour saisir ces détails spécifiques ou n’est tout simplement pas accessible en mobilité (tablette/smartphone). De fait, on assiste à la prolifération de fichiers Excel gigantesques gérés en parallèle.

L’ERP n’a pas de champ pour la « date de validité du dernier DPE » ? Le service technique crée un Excel. Conséquence : on se retrouve avec des versions de fichiers qui circulent par mail, des erreurs de saisie, et surtout, l’information reste locale. Si le fichier Excel est perdu ou si la personne est absente, l’information disparaît pour le reste de l’entreprise.

Peux-tu m’expliquer l’enjeu de la gestion des données de référence ?

C’est l’enjeu critique, surtout à la suite des fusions, car chaque logiciel a sa propre « langue ». Prenons l’exemple de la structure du patrimoine :

• L’ERP découpe le patrimoine en 6 niveaux : Société > Tranche > Résidence > Bâtiment > Entrée > Lot.
• L’outil de diagnostic technique ne connaît que 4 niveaux.
• Le CRM identifie un locataire par son email, l’ERP par un code tiers.

Si vous n’avez pas un système de transcodification (une « pierre de Rosette » informatique), vous ne pouvez pas réconcilier les données. Vous risquez d’envoyer un diagnostic plomb sur tout un immeuble alors qu’il ne concernait qu’un lot, ou de payer des impôts fonciers sur un bâtiment qui a été démoli ou cédé, simplement parce que l’information n’est pas redescendue au bon niveau dans l’ERP.

L’enjeu est donc de créer un référentiel unique (MDM pour Master Data Management ) qui dit : « Voici la vérité sur le Tiers ou le Patrimoine », et qui traduit cette vérité pour que chaque logiciel la comprenne.

Existe-t-il des stratégies pour libérer les données sans tout changer ?

Changer d’ERP est un projet pharaonique, coûteux et risqué. La stratégie gagnante aujourd’hui n’est pas de remplacer l’ERP, mais de le “désacraliser”. Il ne doit plus être le maître absolu de la donnée, mais un contributeur parmi d’autres. La solution consiste ici à mettre en place une couche d’intermédiation avec l’urbanisation du SI.

Dans les faits, il faut garder ce que l’ERP fait bien (la facturation, le quittancement), mais extraire la gestion des « Objets Métiers » (le client, le contrat, le bâtiment) pour les gérer dans un référentiel transverse, agile et ouvert. C’est ce que permet de faire une plateforme comme Phoenix, qui fait le pont entre l’ancien et le nouveau monde. Son rôle : faire le pivot.

• L’ESB (Enterprise Services Bus) (bus de services) va aller chercher la donnée là où elle est (même dans un vieux fichier plat ou une base DB2) et la transporter. Il remplace les traitements batchs nocturnes par des échanges au fil de l’eau, réduisant la latence de 48h à quelques minutes.

• Le MDM (Master Data Management) va nettoyer cette donnée, la dédoublonner (Mr Dupont dans l’ERP et Mr Dupond dans le CRM ne sont qu’une seule et même personne) et la consolider.

• L’API Management va exposer cette donnée propre et fiable aux applications modernes (Application mobile du gardien, Extranet du locataire) de manière sécurisée et standardisée.

“La clé pour moderniser le SI des bailleurs sociaux, c’est d’apporter de l’agilité et de l’innovation en façade, tout en composant avec la rigidité du Back-Office, sans rupture de service”.