Concevoir un écosystème numérique associatif : retour d'expérience Product Engineering sur AOSADS

Le projet AOSADS est souvent résumé par son application de gestion des demandes sociales.

C'est une partie importante du système, mais ce n'est pas toute l'histoire.

La mission a progressivement pris la forme d'un écosystème numérique associatif : un site institutionnel public, une application métier, des parcours d'accès, des règles de traitement, des automatisations et des outils de collaboration pour soutenir les échanges.

Le sujet n'était pas seulement de mettre un processus administratif en ligne. Le vrai sujet était de rendre ce processus lisible, accessible, traçable et maintenable.

Cette rétrospective revient sur les décisions de conception qui ont permis de dépasser la logique du simple formulaire pour construire un système numérique cohérent.

Contexte

L'Association des Œuvres Sociales de l'Agence du Développement Social devait gérer plusieurs catégories de demandes sociales :

• soutien scolaire ;
• mutuelle santé ;
• résidences d'estivage ;
• hôtels d'estivage ;
• subventions ;
• pèlerinage ;
• retraite ;
• décès ;
• autres prestations sociales.

Chaque demande possédait son propre parcours administratif.

Certaines nécessitaient des pièces justificatives. D'autres dépendaient de campagnes annuelles, de règles particulières ou de validations successives. Le problème n'était donc pas seulement la collecte d'informations.

Le problème était la gestion du cycle de vie complet des demandes.

En parallèle, l'association avait besoin d'une présence publique plus claire. Les membres, les ayants droit ou les personnes cherchant AOSADS sur Google devaient pouvoir identifier le site officiel, comprendre le rôle de l'association et accéder à l'espace applicatif.

Les enjeux métier

Avant la mise en place de l'écosystème, les demandes et les échanges pouvaient circuler à travers plusieurs canaux :

• appels téléphoniques ;
• emails ;
• documents papier ;
• fichiers Excel ;
• messageries instantanées ;
• relances manuelles.

Chaque canal répondait à un besoin immédiat, mais aucun ne constituait une source de vérité centralisée.

Une demande pouvait être annoncée par téléphone, complétée par email, suivie dans un tableau, puis traitée par une autre personne. La conséquence n'était pas seulement une perte de temps : c'était surtout une perte de visibilité sur l'état réel des dossiers.

Pour un système de demandes sociales, cette visibilité est structurante. Elle conditionne la confiance des adhérents, la capacité de traitement des gestionnaires et la qualité des décisions prises.

Pourquoi une simple application ne suffisait pas

Une erreur fréquente dans les projets de digitalisation consiste à réduire le besoin à un formulaire web.

Un formulaire permet de collecter une information. Il ne suffit pas à gérer :

• des rôles ;
• des droits d'accès ;
• des statuts ;
• des transitions ;
• des validations ;
• des justificatifs ;
• des notifications ;
• des tableaux de bord ;
• des traces de traitement.

Dans AOSADS, une demande sociale est un objet métier.

Elle possède un propriétaire, un type, un ensemble de données, des pièces justificatives, un historique, un état et un cycle de vie. La première décision importante a donc été de modéliser ces objets avant de penser aux écrans.

Cette approche change la nature du projet. On ne développe plus seulement une interface : on conçoit un système d'information métier.

Une approche orientée Product Engineering

L'approche Product Engineering a consisté à traiter le projet comme un système complet, pas comme une addition de briques techniques.

Il fallait faire tenir ensemble plusieurs dimensions :

• le métier, avec ses règles, ses campagnes et ses validations ;
• l'expérience utilisateur, côté adhérents comme côté gestionnaires ;
• l'architecture de l'information, pour rendre les contenus et les services compréhensibles ;
• le SEO technique, pour rendre le site institutionnel trouvable ;
• l'automatisation, pour réduire les tâches répétitives ;
• la collaboration, pour fluidifier les échanges autour du projet et des traitements.

Le résultat attendu n'était pas une démonstration technique. Le résultat attendu était un environnement utilisable, maintenable et compréhensible par les personnes qui en dépendent.

L'application métier Drupal

Drupal a été retenu comme cœur métier de l'application.

Ce choix était pragmatique. Le besoin ne justifiait pas de reconstruire de zéro des briques que Drupal sait déjà fournir correctement :

• gestion des utilisateurs ;
• rôles et permissions ;
• formulaires structurés ;
• vues de gestion ;
• extensibilité ;
• workflows ;
• notifications ;
• exposition de données via API.

Les développements spécifiques ont donc pu se concentrer sur les règles propres à AOSADS.

La demande est devenue l'entité centrale du système. Chaque demande peut être rattachée à un adhérent, typée, renseignée, suivie, traitée et historisée. Les gestionnaires disposent d'une lecture plus structurée de l'activité, tandis que les adhérents peuvent suivre leur parcours dans un espace dédié.

Modéliser les workflows

La modélisation des workflows a été l'un des principaux leviers de valeur.

Sans workflow explicite, une demande reste une information isolée. Avec un workflow, elle devient un dossier dont l'état est compréhensible :

• créé ;
• complété ;
• pris en compte ;
• traité ;
• validé ou refusé selon les règles applicables ;
• clôturé lorsque le processus est terminé.

Cette logique permet de réduire les ambiguïtés. Elle rend les responsabilités plus lisibles et limite les changements arbitraires d'état.

Elle facilite aussi l'évolution. Quand une campagne change, il devient possible de raisonner sur des règles et des transitions plutôt que sur une accumulation de traitements manuels.

Automatiser sans masquer le métier

Certaines tâches répétitives n'apportent pas de valeur lorsqu'elles restent manuelles :

• activation de compte ;
• complétion de profil ;
• notifications ;
• redirections ;
• contrôles simples ;
• rappels liés à certains événements.

L'automatisation a été utilisée pour alléger ces tâches, mais sans rendre le système opaque.

Dans un contexte administratif, l'automatisation ne doit pas cacher la décision. Elle doit encadrer les étapes, réduire les erreurs et laisser une trace exploitable.

C'est une distinction importante : automatiser un processus ne signifie pas supprimer le métier. Cela signifie rendre ses règles plus explicites.

Le site institutionnel Next.js

Le site institutionnel a été conçu comme la face publique de l'écosystème.

Son rôle n'est pas le même que celui de l'application Drupal. Il ne porte pas le cœur du traitement métier. Il sert de point d'entrée officiel pour présenter l'association, orienter les visiteurs et créer un chemin clair vers les services en ligne.

Next.js a été utilisé pour construire ce site public bilingue FR/AR avec une logique de performance, de structure éditoriale et de découvrabilité.

Cette séparation des responsabilités est importante :

• le site institutionnel explique, publie et oriente ;
• l'application Drupal authentifie, structure et traite ;
• les liens entre les deux rendent le parcours plus naturel pour les membres.

L'écosystème gagne ainsi en lisibilité. Une personne qui cherche l'association n'arrive pas directement dans une interface applicative. Elle trouve d'abord un espace public qui donne du contexte, puis peut rejoindre l'application métier lorsque c'est pertinent.

Une stratégie SEO pensée dès la conception

Le SEO n'a pas été abordé comme une couche ajoutée en fin de projet.

Dans ce contexte, le SEO technique répond à un besoin simple : permettre aux personnes qui cherchent AOSADS, ses services ou son site officiel de trouver un point d'entrée fiable.

Cela implique de travailler plusieurs aspects dès la conception :

• structure des pages ;
• hiérarchie des contenus ;
• lisibilité des intitulés ;
• accès aux versions linguistiques ;
• performance du site public ;
• cohérence entre contenus institutionnels et accès applicatif.

L'objectif n'était pas de produire du trafic pour le trafic. L'objectif était de soutenir la découvrabilité de l'association et de réduire la friction entre recherche, information et accès aux services.

Architecture de l'information et communication numérique

Un écosystème numérique associatif doit aussi clarifier ce qui relève de la communication publique et ce qui relève de la gestion interne.

Le site institutionnel porte les informations publiques : présentation, services, orientation, accès. L'application métier porte les dossiers, les règles, les statuts, les droits et les traitements.

Cette séparation évite deux écueils :

• transformer le site public en espace administratif confus ;
• exposer l'application métier comme unique point d'entrée, sans contexte institutionnel.

L'architecture de l'information sert donc directement le produit. Elle aide les utilisateurs à comprendre où ils sont, ce qu'ils peuvent faire et vers quel espace se diriger.

Communication et collaboration avec KSuite

Le projet a également nécessité une logique de collaboration autour des échanges.

L'intégration avec Infomaniak KSuite a permis de mieux structurer les communications collaboratives liées au projet et à l'organisation des échanges.

Ce point peut sembler périphérique, mais il ne l'est pas. Un système numérique ne vit pas uniquement dans son code. Il vit aussi dans les échanges qui permettent de le faire évoluer, de clarifier les besoins et de traiter les situations qui ne sont pas encore couvertes par l'automatisation.

Dans une approche Product Engineering, ces outils font partie de l'environnement produit. Ils contribuent à la continuité entre conception, exploitation et amélioration.

Les difficultés rencontrées

La principale difficulté n'était pas technique.

Elle consistait à formaliser un métier largement implicite.

Transformer des habitudes de travail en règles exploitables demande des itérations. Il faut identifier les vrais objets métier, comprendre les responsabilités, distinguer les cas standards des exceptions et éviter de figer trop tôt des règles encore instables.

Trois sujets ont demandé une attention particulière.

Les droits d'accès

Une mauvaise configuration des permissions peut exposer des données sensibles.

Le système devait garantir qu'un adhérent ne voie que ses propres demandes, que les rôles autorisés accèdent aux dossiers appropriés et que les gestionnaires disposent des permissions nécessaires sans élargir inutilement l'exposition des données.

La qualité des données

Une demande mal renseignée génère des coûts de traitement.

Les formulaires ont donc été structurés autour de champs obligatoires, listes de choix, validations et règles métier. L'objectif était de guider la saisie sans rendre le parcours inutilement lourd.

L'évolution des campagnes

Certaines demandes, notamment liées à l'estivage, peuvent évoluer selon les périodes, les critères ou les capacités disponibles.

Le système devait rester suffisamment flexible pour intégrer de nouvelles règles sans imposer une refonte complète.

Les résultats observables

Les bénéfices du projet se situent à plusieurs niveaux.

Côté métier, les demandes sont mieux structurées, les états sont plus lisibles et le traitement repose sur des règles plus explicites.

Côté adhérents, le parcours devient plus compréhensible : le site institutionnel sert de point d'entrée public, puis l'application permet d'accéder aux services et de suivre les demandes.

Côté organisation, les tâches répétitives sont progressivement automatisées et les échanges peuvent s'appuyer sur un environnement plus cohérent.

Sans inventer de métriques, on peut résumer la valeur ainsi : moins de dispersion, plus de traçabilité, une meilleure séparation entre communication publique et gestion métier, et une base plus maintenable pour les évolutions futures.

Ce que je ferais différemment aujourd'hui

Plusieurs choix seraient conservés :

• Drupal comme socle métier ;
• Next.js pour le site institutionnel public ;
• séparation entre communication et traitement ;
• modélisation autour des demandes ;
• approche hybride entre configuration, développement spécifique et automatisation.

D'autres aspects seraient probablement renforcés plus tôt :

• formalisation des workflows dès les premiers ateliers ;
• documentation métier plus détaillée ;
• tests automatisés sur les scénarios critiques ;
• architecture de notifications plus robuste ;
• tableaux de bord plus riches ;
• gouvernance éditoriale du site institutionnel.

L'expérience confirme qu'un système métier évolue constamment. Préparer cette évolution est souvent plus important que répondre parfaitement au besoin du jour.

Les enseignements Product Engineering

Le principal enseignement du projet AOSADS est qu'un processus administratif ne devient pas numérique parce qu'il est accessible depuis un navigateur.

La valeur apparaît lorsque les objets métier sont correctement modélisés, que les workflows sont explicites, que les responsabilités sont définies, que les données sont structurées et que le système reste maintenable.

Mais cette rétrospective ajoute un autre enseignement : la valeur ne se limite pas au back-office.

Dans un projet associatif, la présence publique, la découvrabilité, l'architecture de l'information et l'accès aux services font partie du produit. Le site institutionnel Next.js et l'application Drupal ne sont pas deux projets isolés. Ils forment deux faces d'un même système.

Ce que je retiens aujourd'hui

AOSADS illustre bien ce que j'entends par Product Engineering.

Il ne s'agit pas de choisir une technologie puis de la déployer. Il s'agit de comprendre un contexte, de distinguer les responsabilités, de rendre les règles visibles, de construire les bons points d'entrée et d'automatiser ce qui peut l'être sans perdre le sens métier.

Au final, le projet n'a pas consisté à développer une application supplémentaire.

Il a consisté à transformer des pratiques dispersées en un écosystème numérique associatif capable de soutenir durablement la communication, l'accès aux services et le traitement des demandes sociales.