Les DSI de l’habitat social sont en train de changer de métier
Nextra était présent au Congrès HLM, à Bordeaux. Nos équipes sont revenues avec une conviction se confirme : 2027 sera l’année d’un nouveau modèle de système d’information pour les bailleurs sociaux.
Depuis deux ans, les échanges que nous menons chez Nextra avec plusieurs DSI de l’habitat social convergent progressivement vers les mêmes questions. Comment réduire la dépendance aux ERP historiques ? Jusqu’où aller dans une logique best of breed ? Comment organiser la donnée lorsque le SI se fragmente ? Et, surtout, quel doit être le rôle de la DSI dans cette nouvelle organisation ?
Le Congrès HLM a renforcé cette impression. Les discussions ne portent plus uniquement sur le choix d’un logiciel ou sur le remplacement d’une solution vieillissante. Elles touchent désormais à la manière même de concevoir le système d’information.
Pendant longtemps, l’ERP a constitué la colonne vertébrale du SI des bailleurs : gestion locative, patrimoine, quittancement, comptabilité, états des lieux, relation client… Une grande partie des processus et des données reposaient sur un socle unique.
Ce modèle est aujourd’hui largement questionné parce que les bailleurs disposent désormais de davantage d’alternatives et que les besoins des métiers nécessitent une maitrise totale des données.
Cette évolution fait émerger quatre défis majeurs pour les prochaines années.
1. Sortir du « tout ERP »… mais comment quittancer ?
La sortie progressive de certaines fonctions de l’ERP n’est plus vraiment une exception.
Relation client, états des lieux, maintenance, gestion du patrimoine, attributions, recouvrement, pilotage des opérations immobilières… sur beaucoup de périmètres, des solutions spécialisées proposent désormais des réponses plus ergonomiques, plus ouvertes ou plus proches des besoins métiers.
Le modèle best of breed gagne donc naturellement du terrain : plutôt que de demander à un ERP généraliste de répondre correctement à l’ensemble des besoins, le bailleur sélectionne les outils les plus pertinents pour chaque grand domaine fonctionnel.
Mais cela soulève une question complexe : jusqu’où peut-on réduire l’empreinte de l’ERP ?
Certaines briques sont relativement faciles à isoler. D’autres le sont beaucoup moins, comme le quittancement.
Il se situe au cœur de la gestion locative et entretient des liens étroits avec la comptabilité, les charges, les contrats, les aides au logement, les encaissements ou encore les processus de recouvrement.
On peut donc sortir progressivement des fonctionnalités périphériques tout en restant fortement dépendant de l’ERP pour cette fonction centrale.
C’est d’ailleurs ce que l’on retrouve dans beaucoup de trajectoires : les organismes commencent par des briques métier plus autonomes et repoussent le quittancement ou la comptabilité à une phase ultérieure.
L’apparition de nouveaux acteurs capables de se positionner sur ce cœur fonctionnel, comme Ublo, change néanmoins progressivement le paysage. Elle permet d’envisager des scénarios qui étaient encore difficiles à crédibiliser il y a quelques années.
Mais l’enjeu ne se résume pas au choix d’un nouvel outil : la vraie question est celle de la trajectoire.
Faut-il basculer rapidement vers une nouvelle architecture ou avancer progressivement ? Comment organiser la coexistence temporaire entre l’ancien et le nouveau SI ? Quelles interfaces construire ? Et surtout, comment éviter qu’une sortie de l’ERP ne conduise à une explosion des coûts de licences, d’intégration et de maintenance ?
Le sujet n’est donc pas « ERP ou best of breed », mais de passer d’une logique de remplacement d’outil à une véritable stratégie d’architecture.
2. Maîtriser et organiser les référentiels métier
Quand les fonctions sont réparties entre plusieurs applications, une question devient incontournable :
où se trouve la donnée de référence ?
Lorsque l’ensemble du système repose principalement sur un ERP, la réponse semble relativement simple : la donnée est dans l’ERP.
Dans une architecture plus distribuée, ce raisonnement ne tient plus.
Quelle application est maître de la donnée patrimoine ? Où se trouve le référentiel des logements ? Qui porte le référentiel locataire ? Où est géré le contrat ? Quelle application doit être considérée comme source lorsqu’une information apparaît à plusieurs endroits ?
Ces questions peuvent sembler très techniques. Elles le sont beaucoup moins qu’il n’y paraît.
Derrière la notion de référentiel se cache surtout un enjeu de responsabilités.
Prenons un référentiel patrimoine. Qui crée un nouveau bâtiment dans le système ? À quel moment ? Qui crée les logements associés ? Qui enrichit ensuite les informations techniques ? Comment sont prises en compte les transformations du patrimoine ? Et que se passe-t-il lorsque deux applications proposent des valeurs différentes ?
Acheter un MDM ou mettre en place une nouvelle base ne répond pas à ces questions.
Pour qu’un référentiel fonctionne, il faut déterminer ses règles de gestion : modalités d’initialisation, processus de mise à jour, contrôles, responsabilités, règles de synchronisation avec les autres outils.
Le sujet devient alors autant organisationnel que technologique.
La DSI peut mettre en place les outils nécessaires. Elle peut structurer les flux, proposer une architecture de données ou organiser les contrôles. Mais elle ne peut pas décider seule de la définition d’un logement, d’un équipement patrimonial ou d’un statut locataire.
Ces décisions relèvent des métiers.
C’est l’une des évolutions importantes que nous observons aujourd’hui : la transformation du SI oblige à clarifier la gouvernance de la donnée.
Qui est data owner ? Qui garantit la qualité ? Quels contrôles doivent être réalisés ? Quel indicateur permet de vérifier que le référentiel est à jour ?
Dans un environnement best of breed, les référentiels deviennent ainsi un élément structurant de l’architecture.
Ils permettent de ne plus faire dépendre la donnée stratégique d’une application particulière. Et ils facilitent les évolutions futures : changer un outil devient beaucoup plus simple lorsque les données structurantes sont maîtrisées indépendamment de celui-ci.
3. Passer de l’interfaçage à l’orchestration
Le best of breed apporte de la souplesse, mais il crée également une nouvelle forme de complexité.
Plus d’applications signifie mécaniquement plus de flux.
Chaque nouvelle brique doit échanger avec d’autres : récupérer des informations sur les locataires, transmettre des données au CRM, actualiser le patrimoine, déclencher une communication, envoyer une écriture vers la comptabilité…
Très vite, le nombre d’interfaces augmente.
Le risque serait alors de remplacer un ERP monolithique par un SI constitué d’une multitude de connexions point à point, difficiles à superviser et encore plus difficiles à faire évoluer.
Dans ce contexte, savoir interconnecter les applications ne suffit plus.
Il faut être capable de les orchestrer.
Cela implique notamment de centraliser et superviser les flux, de tracer les échanges, de détecter les erreurs, de rejouer certains traitements ou encore de gérer des règles transverses entre plusieurs systèmes.
Prenons un processus relativement simple : l’arrivée d’un nouveau locataire.
Plusieurs systèmes peuvent être concernés : gestion locative, signature électronique, espace locataire, CRM, éditique, gestion documentaire, éventuellement comptabilité.
Une logique d’interfaçage consiste à construire des connexions entre ces différentes applications.
Une logique d’orchestration consiste à piloter l’ensemble du processus : lorsque le contrat est signé, telle donnée est mise à jour, tel document est créé, tel accès est ouvert, telle communication est déclenchée et une alerte est générée si une étape échoue.
La différence peut sembler subtile, mais elle est structurante.
Dans le premier cas, on connecte des applications.
Dans le second, on pilote un processus qui traverse plusieurs applications.
C’est probablement l’un des changements les plus importants pour les DSI qui s’orientent vers des architectures plus ouvertes.
La compétence clé n’est plus seulement de sélectionner et déployer des outils, mais de construire un environnement dans lequel ces outils peuvent fonctionner ensemble de manière fiable.
Et c’est aussi dans cet espace que l’IA pourrait progressivement prendre une place intéressante.
Pas uniquement sous la forme d’un assistant présent dans chaque logiciel, mais comme une composante capable d’interpréter une information, de déclencher une action ou d’enrichir un processus transversal.
4. Repenser le rôle de la DSI avec les métiers
Cette transformation du SI entraîne forcément une transformation de la DSI.
Et c’est peut-être finalement le sujet le plus important.
Les DSI avec lesquelles nous échangeons expriment régulièrement la même volonté : être partenaires des métiers sans se substituer à eux.
La nuance est essentielle.
Dans un modèle très centralisé autour d’un ERP, la frontière pouvait sembler relativement claire. La DSI administrait le système et les métiers l’utilisaient.
Avec l’essor du best of breed, du low-code, de la data et aujourd’hui de l’IA, cette séparation devient beaucoup moins nette.
Les métiers peuvent identifier directement des solutions SaaS, construire certaines automatisations, produire des tableaux de bord ou expérimenter des outils d’IA.
La DSI ne peut donc plus être uniquement un fournisseur de solutions.
Son rôle devient davantage celui d’un architecte et d’un facilitateur.
Elle apporte le cadre d’ensemble : architecture, sécurité, urbanisation, intégration, choix technologiques, gouvernance de la donnée.
Elle apporte également une connaissance du marché et une capacité à comparer les solutions.
Mais les métiers doivent rester propriétaires de leurs processus.
Ce sont eux qui doivent expliquer comment doit fonctionner un processus d’attribution, quelles règles doivent s’appliquer à un contrat, quelles données sont importantes dans un référentiel patrimoine ou comment doit être traité un dossier locataire.
Cette responsabilisation des métiers est indispensable.
Sans elle, la DSI risque de devenir propriétaire de règles de gestion qui ne lui appartiennent pas. Et les métiers peuvent progressivement considérer le fonctionnement du SI comme un sujet exclusivement informatique.
Le modèle qui se dessine est donc beaucoup plus partenarial.
La DSI apporte les méthodes et le cadre. Les métiers apportent la connaissance du processus et assument la responsabilité fonctionnelle.
Cela nécessite aussi de nouvelles compétences : chefs de projet plus proches des métiers, responsables data, data stewards, profils capables de comprendre à la fois les processus et les technologies.
Le changement d’architecture entraîne donc également un changement d’organisation.
Et l’IA dans tout cela ?
Il y a encore peu de temps, les discussions autour de l’IA commençaient souvent par une question : « faut-il y aller ? »
Cette phase semble progressivement derrière nous.
Dans les DSI que nous rencontrons, l’IA est désormais un sujet installé.
Les approches restent très différentes. Certains organismes déploient des assistants généralistes. D’autres expérimentent des cas d’usage ciblés. Certaines DSI commencent même à développer leurs propres applications plutôt qu’à attendre qu’un éditeur fournisse la fonctionnalité recherchée.
Le niveau de maturité varie, mais la question n’est plus réellement de savoir s’il faut expérimenter.
Le prochain enjeu sera celui de l’industrialisation.
Quels cas d’usage méritent réellement d’être déployés à grande échelle ? Sur quelles données peuvent-ils s’appuyer ? Comment intégrer ces nouveaux usages au SI existant ? Quelle gouvernance mettre en place ? Comment mesurer la valeur créée ?
Et surtout : comment éviter d’ajouter une nouvelle couche d’outils sans remettre à plat les processus ?
L’IA ne remplace pas les sujets précédents. Au contraire, elle les rend encore plus importants.
Une IA qui exploite des données mal organisées produira difficilement des résultats fiables.
Une IA qui doit intervenir dans plusieurs applications aura besoin d’une architecture ouverte et de flux bien maîtrisés.
Et une IA qui prend place dans un processus métier nécessitera une définition claire des responsabilités entre la technologie, les agents et les directions.
L’IA est donc moins un chantier séparé qu’un accélérateur de la transformation en cours.
Vers un nouveau modèle de SI pour les bailleurs sociaux
Pendant longtemps, l’enjeu principal consistait à faire évoluer ou remplacer un ERP.
Aujourd’hui, les questions deviennent plus larges : comment construire un SI modulaire sans créer de complexité ? Comment conserver la maîtrise de la donnée ? Comment permettre aux outils de dialoguer ? Et comment organiser la responsabilité entre la DSI et les métiers ?
Le modèle cible ne sera probablement pas identique pour tous les bailleurs.
Certains conserveront un ERP très structurant en y connectant quelques solutions spécialisées. D’autres réduiront progressivement son périmètre. D’autres encore iront plus loin dans une architecture best of breed.
L’enjeu n’est donc pas de définir un modèle unique.
Il est de construire une architecture cohérente avec la stratégie, les moyens et la maturité de chaque organisme.
C’est précisément pour cette raison que le rôle des DSI évolue.
Elles ne pilotent plus seulement des projets informatiques. Elles doivent désormais organiser un écosystème de solutions, de données, de flux et de responsabilités.
Et c’est probablement là que se situe l’un des grands chantiers de l’habitat social pour 2027.