Ascensus

Quarante-cinq marques, c'est beaucoup pour une petite équipe. Quarante-cinq marques qui appartiennent à quelqu'un d'autre, c'est plus difficile encore.

Chaque site a sa propre identité, parce que chaque État et chaque partenaire y tient. C'est là que se trouve le piège du multimarque. Si chaque marque devient un projet à part entière, vous finissez par tout maintenir en 45 exemplaires : 45 bases de code, 45 mises à jour à appliquer, et un développement spécifique chaque fois qu'une marque veut un nouveau type de page.

Les demandes arrivent par ailleurs de quatre canaux à la fois. Les équipes marketing d'Ascensus envoient les maquettes des sites dont elles ont la charge. Les partenaires et leurs agences transmettent des demandes de landing pages et des modifications de contenu via les responsables de comptes. Les clients directs passent par le même circuit. Et les équipes produit ont besoin de contenus pour leurs applications.

Comme les marques appartiennent aux clients, rien ne peut se faire à l'approximation. Aucune modification n'atteint un site en production sans passer par une équipe unique, qui sait ce que chaque marque autorise. Ici, la gouvernance n'est pas une formalité administrative. C'est ce qui permet à un État de confier son plan à Ascensus.

S'ajoute à cela la nature des engagements. Ces contrats publics garantissent 99,9 % de disponibilité. Un site indisponible n'est pas un incident interne : c'est un incident client.

L'ancien système ne pouvait rien porter de tout cela. Il ne permettait pas de produire des sites responsive : l'équipe maintenait donc deux versions de chaque site, une pour le bureau et une pour le mobile. Créer une seule page supposait de créer au préalable un fichier distinct pour chaque image et chaque PDF, souvent dix ou plus avant même de commencer la page.

Voici ce qui rend 45 marques gérables. Ascensus construit une seule fois ce que les marques ont en commun, et ne fait varier que la marque.

L'équipe ne construit pas 45 sites web. Elle construit un jeu de composants (une bannière, un tableau comparatif, un bloc de contact) qu'elle maintient dans le code. Chaque composant peut exister sous plusieurs apparences : mise en page différente, styles différents. Au moment de poser un composant sur une page, on choisit l'apparence qui correspond à la marque.

Un seul jeu de briques. Quarante-cinq sites qui ne se ressemblent pas.

Le partage est net. Mutualisé une fois pour les 45 sites : les composants, le code, le circuit de publication, l'architecture de disponibilité et les compétences de l'équipe. Propre à chaque site : le design, le contenu, la marque. Rien de spécifique à une marque n'est construit deux fois, et rien de mutualisé n'est reconstruit marque par marque.

Le site d'un nouveau plan devient pour l'essentiel un nouvel assemblage d'éléments qui existent déjà. Et un nouveau composant devient disponible d'un coup sur les 45 sites.

La gouvernance suit la même logique : un seul circuit, pas 45. Chaque demande devient un ticket, arrive sur un même tableau et est traitée par la même équipe, quelle que soit la marque concernée. Ascensus peut tenir un standard constant sur 45 marques clientes parce qu'il n'existe qu'un seul endroit où les modifications se font.

Ce même Jahia alimente aussi les applications d'Ascensus. Les contenus sont stockés dans un site Jahia dédié, organisés en dossiers par marque. Un traitement automatisé les récupère via l'API de Jahia, les transforme en fichiers et les transmet aux applications. Ces applications ont été développées en Angular et n'ont jamais été reconstruites autour de Jahia : elles consomment simplement les contenus que Jahia produit. Une seule plateforme couvre donc à la fois les sites web et les contenus des produits.