De zéro à 10 agences en 6 mois : ce qu'on a appris en construisant Loxia pour Crédit Agricole

En 2024, Doxallia, filiale immobilier du groupe Crédit Agricole, nous a confié un mandat clair sur le papier : construire une plateforme de gestion locative AI-native, à l'échelle d'un groupe bancaire, en partant d'une feuille blanche.

Sur le papier. Parce qu'à l'arrivée, il n'y avait ni scoping produit, ni équipe constituée, ni plan de delivery. Juste une intention stratégique forte — et un paysage opérationnel fragmenté entre une dizaine d'agences pilotes, chacune avec ses propres process.

Six mois plus tard, Loxia tournait en production sur 10 agences. Voici ce qu'on a appris en chemin — et pourquoi ce projet ressemble à 80% des mandats AI qui atterrissent chez nous.

Le point de départ : intention forte, zéro fondation

Le contexte métier était simple à formuler. Un candidat locataire dépose un dossier — bulletins de paie, contrat de travail, pièce d'identité, avis d'imposition. Un gestionnaire en agence relit chaque pièce, vérifie la cohérence, calcule le taux d'effort, repère les anomalies, valide ou refuse.

Coût observé : 30 à 45 minutes de review humaine par dossier. Multiplié par le volume d'un groupe bancaire, ça devient un poste de charge significatif. Pire : malgré le temps passé, certaines fraudes documentaires passaient. Bulletins retouchés, contrats de travail fictifs, justificatifs domiciliaires bricolés. Pas systématique, mais suffisant pour faire mal.

L'intention de Doxallia était nette : industrialiser ce processus, sécuriser la détection de fraude, libérer du temps en agence. L'AI-native était le moyen, pas la fin.

Mais quand on a démarré, on n'a pas trouvé ce qu'on cherche habituellement dans un projet bien câblé. Pas de scoping produit détaillé. Pas d'équipe delivery dédiée. Pas de référentiel data centralisé — chaque agence avait ses propres tableurs, ses propres règles tacites, son propre rapport au risque. Le paysage opérationnel était fragmenté, et personne ne s'en cachait.

C'est exactement le pattern qu'on rencontre dans la majorité des PME et filiales qu'on accompagne. Une direction qui voit juste sur la stratégie. Et un terrain qui n'a jamais été préparé à recevoir ce qu'on veut y planter.

Le vrai défi n'était pas l'IA — il était organisationnel

Soyons honnêtes : le bloc technique de Loxia, en 2024, ne posait pas de problème de R&D. Du parsing de documents, du scoring tabulaire, de la détection d'anomalies — l'état de l'art existait, les modèles étaient matures, les patterns connus.

Le vrai défi était ailleurs : aligner Product, IT groupe, agences pilotes et partenaires data sous une cadence unique, sous contraintes bancaires. Et faire en sorte que cet alignement tienne pendant six mois consécutifs.

Concrètement, ça veut dire arbitrer entre :

• Le Product, qui veut itérer vite sur des prototypes utilisateurs réels.
• L'IT groupe, qui doit valider chaque brique sous l'angle conformité, sécurité, hébergement.
• Les agences, qui veulent un outil qui ressemble à leur métier — pas à une démo SaaS.
• Les partenaires data (fournisseurs de signaux externes), qui ont leurs propres cycles contractuels et leurs propres SLA.

Aucun de ces acteurs n'est l'ennemi. Mais chacun pousse dans une direction légèrement différente, à une cadence différente. Et dans un groupe bancaire, personne n'a autorité unilatérale. Tout se négocie, tout se documente, tout passe par des comités.

Notre vrai job sur les premiers mois n'a pas été d'écrire du code. Il a été de poser une cadence de delivery hebdomadaire lisible par tous, avec des arbitrages explicites et tracés. Une fois cette cadence en place, le reste a suivi.

L'architecture qu'on a posée

Sur le bloc tech, on est resté pragmatique. React, Next.js, TypeScript côté front. Node.js côté API. MongoDB pour le stockage applicatif et les artefacts documentaires. OVH pour l'hébergement — choix dicté par la souveraineté des données et la conformité bancaire française.

Pas de stack exotique. Pas de framework émergent qu'on aurait été le seul à maîtriser. Quand on livre à un groupe bancaire, on optimise pour la transférabilité : l'IT groupe doit pouvoir reprendre, auditer, faire évoluer la plateforme sans qu'on devienne un point de dépendance unique.

Le pipeline IA s'articulait autour de trois briques :

1. Document AI. Extraction structurée depuis bulletins de paie, contrats de travail, pièces d'identité, avis d'imposition. L'enjeu n'était pas la précision brute du parsing — il était la gestion des cas dégradés : scans de mauvaise qualité, formats régionaux, mises en page variables d'un employeur à l'autre. On a passé beaucoup plus de temps sur les 10% de cas tordus que sur les 90% standards.

2. Scoring de solvabilité. À partir des données extraites + signaux externes, calcul d'un score d'adéquation candidat/logement. Le scoring n'a jamais été présenté comme une décision automatique — c'est un outil d'aide au gestionnaire, avec explicabilité des facteurs qui pèsent. On y reviendra.

3. Détection de fraude documentaire. Croisement de signaux : cohérence interne d'un document, cohérence entre documents (le nom sur le bulletin matche-t-il le contrat ?), détection d'altérations sur la pièce elle-même. L'IA flague, l'humain tranche.

Sur les trois briques, on a posé un principe simple : l'IA arbitre les volumes, l'humain garde la décision sur les cas à risque. C'est cette frontière qui a structuré toute la conception produit.

Ce qui n'a pas marché du premier coup

La première itération du scoring de solvabilité n'a pas convaincu les agences. Pas parce que le modèle était mauvais — il sortait des scores cohérents avec ce qu'un gestionnaire expérimenté aurait produit. Mais parce qu'il sortait juste un nombre.

Un score, sans explication, ne sert à rien à un gestionnaire qui doit assumer la décision finale. Pire : ça transfère le risque cognitif sur lui sans lui donner les leviers pour le maîtriser. Si le score est élevé et le dossier explose six mois plus tard, c'est lui qui se justifie en interne — pas le modèle.

On a refait toute la couche d'explicabilité. Chaque score est décomposé en facteurs (taux d'effort, stabilité de l'emploi, qualité des justificatifs, signaux externes), avec une visualisation claire et un seuil de confiance. Le gestionnaire ne valide pas un nombre — il valide un raisonnement.

L'autre point qui a coincé : l'harmonisation des process inter-agences. Chaque agence avait ses propres règles tacites — seuils, exceptions, traitements particuliers selon le profil. Construire un outil unique qui respecte ces variations sans devenir une usine à gaz a demandé plusieurs itérations sur le paramétrage.

On a fini par traiter ça comme un problème de configuration métier, pas de code : chaque agence configure ses seuils et ses règles dans une interface dédiée, et la plateforme s'adapte. Ça aurait été tentant de "standardiser" — c'est exactement le piège dans lequel beaucoup de projets équivalents tombent. On ne livre pas un produit AI à une organisation en lui imposant d'abord de changer ses process. On livre un produit qui se plie à l'organisation existante, puis on l'aide à converger.

C'est aussi pour cette raison que beaucoup de POC IA échouent : ils sont conçus dans un vide organisationnel qui n'existe pas dans la réalité.

Ce qui a vraiment fait la différence

Trois décisions, prises tôt, ont structuré la suite.

Penser produit avant IA. On a passé les six premières semaines sur le parcours utilisateur — pas sur les modèles. Quel est le quotidien d'un gestionnaire ? À quel moment ouvre-t-il un dossier ? Combien de fois bascule-t-il entre outils ? Où sont les frictions actuelles ? L'IA est venue ensuite, comme moyen de résoudre des points précis dans un parcours déjà cartographié. Ça paraît trivial. C'est pourtant le contraire de ce qu'on voit dans 80% des projets AI mal cadrés, où on commence par choisir un modèle et où on cherche ensuite un problème à lui faire résoudre.

Eval grid sur cas réels, pas synthétiques. Pour Document AI comme pour la détection de fraude, on a constitué un jeu d'évaluation à partir de bulletins de paie réels et contrats de travail réels (anonymisés, avec accord). Pas de données synthétiques générées par modèle. Parce qu'un bulletin de paie suisse d'un employeur public n'a rien à voir avec un bulletin français d'un cadre intermittent, et les modèles génératifs n'inventent pas ces nuances — ils les lissent. L'eval grid est devenue notre référence pour valider chaque itération, et pour discuter avec l'IT groupe sur des bases factuelles.

Décision AI/humain explicite, par cas d'usage. Sur chaque brique, on a tranché : où l'AI décide seule (parsing d'un champ standard), où l'AI propose et l'humain valide (scoring), où l'AI alerte et l'humain investigue (fraude). Cette grille est documentée, partagée, et tient lieu de contrat entre la plateforme et ses utilisateurs. Personne en agence ne se demande "est-ce que je peux faire confiance à ce que la machine vient de me dire ?" — la réponse est dans la grille.

Ce qu'on referait, ce qu'on changerait

Ce qu'on referait sans hésiter : investir massivement sur la cadence de gouvernance. Hebdo Product/IT, bi-mensuel agences pilotes, comité mensuel data partenaires. Ça paraît lourd au démarrage. C'est ce qui a permis de livrer en six mois.

Ce qu'on ferait différemment : mettre les agences en boucle plus tôt. On a passé trop de temps sur des prototypes internes avant de les confronter au terrain. Les deux premières démos en agence ont dégagé plus d'enseignements que six semaines de spécification — on aurait dû les faire au mois deux, pas au mois trois.

Et un point qu'on rappelle à tous les dirigeants de PME qu'on rencontre depuis : la qualité de votre data préexistante détermine 60% du succès d'un projet AI. Si vos process sont fragmentés, vos référentiels éclatés, vos justificatifs stockés sur des partages réseau hétérogènes — l'IA n'arrangera rien, elle exposera tout. La phase la plus critique est celle qui n'a rien à voir avec l'IA : structurer la data en amont.

L'angle conformité, qu'on n'a pas pu éviter

Construire ce type de plateforme en environnement bancaire, c'est composer en permanence avec la conformité. Côté français, ACPR sur les aspects bancaires, CNIL sur la protection des données candidats, et tout l'attirail des contrôles internes du groupe. Côté Suisse, pour les PME qui regardent ce qu'on a fait avec Doxallia et qui se projettent sur leur propre marché : FINMA, et bientôt les cadres européens sur l'AI qui vont ruisseler par l'AI Act.

L'enjeu de souveraineté IA en Suisse devient incontournable dès qu'on touche à du scoring, de la décision assistée, de la donnée personnelle sensible. Ce n'est pas une option de conformité qu'on rajoute en fin de projet — c'est un axe structurant qui détermine le choix d'hébergement, de modèles, d'architecture, de logs.

Sur Loxia, le choix OVH, la stack maîtrisable de bout en bout, l'explicabilité du scoring, la traçabilité des décisions IA — tout ça n'était pas du nice-to-have. C'était la condition pour passer en production.

C'est, en pratique, la barrière à l'entrée qui sépare les PoCs qui tournent en démo des plateformes qui tournent en agence. Et c'est probablement le chantier de fond que les PME suisses et françaises vont devoir attaquer sur les 18 prochains mois — qu'elles soient banques, assureurs, gestionnaires d'actifs ou industriels manipulant de la donnée sensible. Loxia a été notre premier terrain pour structurer cette approche. Ce ne sera pas le dernier.