Artisans du bâtiment : moderniser l’écosystème CAPEB sans casser l’existant

La CAPEB accompagne les entreprises artisanales du bâtiment sur tout le territoire. Autour de ce réseau professionnel s'est construit, au fil des années, un écosystème numérique : un site vitrine, un espace utilisateurs, des dispositifs de labellisation. L'échelle est conséquente : des milliers d'artisans concernés, des dizaines de labels à faire vivre dans le système. Quand le moment est venu de le refondre, ce n'est pas un simple « refaire le site » : c'est reprendre un maillage d'outils, de processus et d'équipes, avec une contrainte forte : une infrastructure existante qu'il fallait respecter.

Le projet nous est arrivé par Copotato, studio parisien avec qui nous collaborons depuis plusieurs années (voir aussi notre retour d'expérience sur le dispositif jeu vidéo en bois). Copotato accompagnait la CAPEB sur la refonte de l'écosystème autour du programme Artisans du bâtiment. Deux volets : la partie vitrine, et la partie métier qui gère les labels. Ils sont venus nous voir parce que la difficulté n'était pas seulement graphique ou éditoriale : il fallait pouvoir s'insérer dans l'existant, côté CAPEB, sans tout casser.

Moderniser ce que voient les utilisateurs tout en restant branché sur un système vieillissant : c'est le cœur du chantier, technique autant qu'humain.

Un existant à respecter, pas à ignorer

Du côté CAPEB, l'infrastructure en place datait déjà de plusieurs années. Pas obsolète au point d'être jetable du jour au lendemain, mais assez ancienne pour imposer des contraintes fortes : échanges par fichiers, passage par le protocole FTP, formats et règles hérités d'une autre époque de développement.

Notre mission : offrir une expérience moderne aux utilisateurs finaux (interface claire, parcours fluide, espace connecté crédible), tout en dialoguant avec ce socle. Pas de big bang : une couche neuve au-dessus d'un fondationnel qu'on ne maîtrisait pas entièrement au départ.

La difficulté technique se résume ainsi : rafraîchir la partie visible (site, espace utilisateur, gestion des labels côté interface) tout en maintenant des ponts fiables vers un arrière-plan fondé sur des échanges de fichiers. Chaque aller-retour FTP est une source de latence, d'erreurs de format et de fragilité opérationnelle. C'était le prix à payer pour livrer sans attendre une refonte totale du SI côté fédération.

Autant de métiers que d'équipes à coordonner

La complexité ne tenait pas qu'au code. Sur le périmètre CAPEB, chaque brique de l'existant est portée par une équipe légèrement différente : une pour tel flux de fichiers, une autre pour telle application, une autre encore pour les règles métier des labels. Obtenir une spec complète, un accès FTP, la documentation d'un format : autant de démarches distinctes.

Sans coordination centrale, le projet aurait stagné dans les interstices organisationnels. C'est là qu'un rôle de product owner fait la différence : quelqu'un qui ne se contente pas de relayer des tickets, mais qui va chercher les bonnes personnes, débloque les accès, remonte les formats réels des fichiers, arbitre quand les réponses divergent.

Chez Copotato, ce rôle a été tenu par Chloé. Pas en figurant : en pilote du projet côté commanditaire. Elle a passé un temps considérable à obtenir les informations qui manquaient, à ouvrir les portes, à faire le lien entre nos questions techniques et les équipes CAPEB. Sans ce travail en amont et en continu, nous aurions livré une belle coque vide.

Deux mondes modernes, un backend de liaison

Nous avons structuré la solution en deux expériences distinctes, reliées par un socle technique commun côté Improba :

• Le site vitrine, confié à WordPress : pages institutionnelles, contenus éditoriaux, mise en avant du programme Artisans du bâtiment. Un CMS éprouvé pour la partie « communication », où les équipes éditoriales gardent la main.
• L'espace utilisateurs, une application web dédiée : parcours connectés, gestion des labels, interactions métier. Interface construite avec Quasar et Vue.js, pour une expérience applicative fluide.

Entre ces deux faces et le système CAPEB, un backend NestJS avec base PostgreSQL assume la logique d'échange : orchestration des flux, traitement des fichiers, dialogue FTP avec l'existant. C'est la « salle des machines » invisible pour l'utilisateur final, mais critique pour la fiabilité du dispositif.

Le projet s'inscrit dans la lignée de notre socle Glutamat : une base technique industrialisée (NestJS, PostgreSQL, patterns applicatifs) sur laquelle nous déroulons le métier en prestation. WordPress reste à part pour le vitrine, ce qui est un choix pragmatique : le bon outil pour le bon usage, sans forcer un monolithe unique.

Livrer à temps : renforts des deux côtés

Sur le papier, le calendrier était serré : quatre mois pour livrer. Nous l'avons tenu. Pas en rognant le périmètre fonctionnel, mais en ajustant les moyens :

• Côté Improba : nous avons mobilisé un peu plus de personnes que prévu initialement, pour raccourcir les cycles de développement et absorber les imprévus d'intégration FTP.
• Côté Copotato : Chloé s'est investie bien au-delà du cadrage initial, notamment pour traquer les informations manquantes et faire ouvrir les accès nécessaires. Ce n'était pas du « plus de réunions » : du travail de terrain sur un écosystème fragmenté.

La leçon est simple et nous la retrouvons sur d'autres chantiers legacy : quand l'intégration dépend d'autrui, le facteur limitant n'est souvent pas le code, c'est la vitesse à laquelle l'organisation fournit ce qu'il faut brancher. Un product owner efficace compresse ce délai.

Ce que nous referions différemment

Le livrable est en place et utilisé. Si c'était à refaire, nous tenterions d'élargir le périmètre dès le cadrage : pas seulement notre couche moderne, mais une réflexion plus franche sur la modernisation des autres applications côté CAPEB.

En restant cantonnés à un pont FTP, nous avons respecté les contraintes du moment. Mais ce pont reste une complexité récurrente : formats à maintenir, files à surveiller, délais d'échange. Si une partie du budget et du temps avait été consacrée à faire évoluer les systèmes en amont, le gain en simplicité globale aurait, nous le pensons, compensé l'ouverture de scope. Moins de couture entre vieux et neuf, plus de continuité native.

Ce n'est pas une critique du choix initial : dans beaucoup de contextes, on ne peut pas attendre une refonte SI complète pour livrer une interface digne de ce nom. C'est un constat pour les projets suivants : parfois, « un peu plus large » au départ évite « beaucoup plus cher » à l'entretien.

Ce que nous en retenons

Artisans du bâtiment illustre un profil de mission que nous rencontrons souvent chez Improba : moderniser l'expérience utilisateur sans détenir les clés de tout le système, s'intégrer à un existant hétérogène, et tenir le délai grâce à un binôme technique + pilotage métier solide.

Copotato et Chloé ont été le relais indispensable vers la CAPEB. Notre stack (WordPress, NestJS, PostgreSQL, Quasar/Vue) a permis de séparer clairement vitrine et applicatif tout en centralisant les échanges. Le FTP a fait le travail de transition ; la prochaine étape, si le contexte s'y prête, serait de le rendre inutile.

Si votre contexte ressemble à celui du départ : refonte d'un écosystème autour d'un programme métier, infrastructure legacy par fichiers, équipes multiples côté commanditaire et besoin d'une interface moderne sans big bang, c'est le type de chantier où nous nous sentons utiles. Voir nos réalisations ou nous écrire pour en parler.