Digitaliser un processus de gestion des demandes sociales : retour d'expérience Product Engineering avec Drupal

Transformer un processus administratif en système métier : retour d'expérience Product Engineering sur AOSADS

Les projets de transformation numérique sont souvent présentés comme des projets de développement logiciel. Pourtant, dans de nombreux contextes administratifs, la difficulté principale n'est pas technique.

Le véritable défi consiste à transformer un ensemble de pratiques, de règles implicites, d'échanges informels et de traitements manuels en un système structuré capable de supporter durablement l'activité.

Le projet AOSADS est un exemple représentatif de cette problématique.

L'objectif n'était pas simplement de mettre en ligne quelques formulaires. Il s'agissait de concevoir une plateforme capable de gérer des demandes sociales, leur traitement, leur suivi et leur évolution dans le temps tout en garantissant traçabilité, sécurité et maintenabilité.

Cette rétrospective revient sur les choix qui ont guidé la conception du système.

Le contexte métier

L'association 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 suivait son propre parcours administratif.

Certaines nécessitaient des pièces justificatives.

D'autres devaient être validées selon des règles particulières.

D'autres encore dépendaient de campagnes annuelles avec des critères évolutifs.

Le problème n'était donc pas la saisie des demandes.

Le problème était la gestion de leur cycle de vie.

Une situation de départ typique des processus administratifs

Avant la mise en place de la plateforme, les demandes circulaient essentiellement à travers plusieurs canaux :

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

Chaque outil répondait à un besoin immédiat.

Aucun ne constituait cependant une source de vérité centralisée.

Une demande pouvait être :

annoncée par téléphone ; complétée par email ; enregistrée dans un tableau Excel ; suivie dans un autre document ; traitée par une autre personne.

La conséquence n'était pas uniquement une perte de temps.

Le véritable problème était l'absence de visibilité globale sur l'état réel des dossiers.

Le défi principal : modéliser le métier

Une erreur fréquente dans les projets de digitalisation consiste à considérer qu'une demande est simplement un formulaire.

Dans AOSADS, une demande est en réalité 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 ; un cycle de vie.

La première étape du projet a donc consisté à transformer des procédures administratives implicites en règles explicites.

Cela a nécessité de répondre à plusieurs questions :

Qui peut créer une demande ? Qui peut la consulter ? Qui peut la traiter ? Quels sont les états possibles ? Quelles informations sont obligatoires ? Quels contrôles doivent être réalisés avant traitement ?

Ce travail de modélisation a représenté une part importante de la valeur du projet.

Les contraintes métier

La gestion de demandes sociales introduit plusieurs contraintes spécifiques.

Confidentialité

Certaines demandes peuvent contenir des informations personnelles ou sensibles.

Le système devait garantir que :

un adhérent ne puisse voir que ses propres demandes ; seuls les rôles autorisés puissent accéder aux dossiers ; les données restent protégées tout au long du cycle de traitement. Traçabilité

Une demande sociale peut être examinée plusieurs fois.

Il devait être possible de savoir :

quand elle a été créée ; qui l'a consultée ; qui l'a traitée ; dans quel état elle se trouve ; quelles décisions ont été prises. Suivi administratif

L'association devait disposer d'une vision consolidée de son activité :

nombre de demandes ; répartition par catégorie ; état des dossiers ; volumes par période ; besoins de traitement. Évolution des règles

Les campagnes changent.

Les critères évoluent.

Les formulaires sont régulièrement ajustés.

Le système devait absorber ces évolutions sans nécessiter une refonte complète.

Les options étudiées Conserver le processus manuel

Cette option présentait un avantage évident :

Aucun changement organisationnel.

Cependant, elle conservait tous les problèmes existants :

absence de visibilité ; erreurs humaines ; duplication d'informations ; faible traçabilité.

Elle a été rapidement écartée.

Utiliser uniquement des formulaires web

Cette approche simplifie la collecte des informations.

Elle ne résout cependant pas la gestion du cycle de vie.

Un formulaire ne remplace pas :

un workflow ; des statuts ; des rôles ; des tableaux de bord ; des mécanismes de suivi. Tout gérer par email

L'email est un canal de communication.

Ce n'est pas un système métier.

Les emails permettent d'échanger.

Ils ne permettent pas de piloter efficacement un portefeuille de demandes.

Développement spécifique complet

Cette option offre une liberté totale.

Elle implique également :

davantage de code ; davantage de maintenance ; davantage de risques.

Pour ce projet, reconstruire entièrement les fonctionnalités déjà disponibles dans Drupal n'apportait pas suffisamment de valeur.

Drupal comme socle métier

Cette approche a finalement été retenue.

Drupal apportait déjà :

la gestion des utilisateurs ; les rôles ; les permissions ; les formulaires ; les vues ; les notifications ; l'extensibilité.

Les développements spécifiques pouvaient alors se concentrer uniquement sur les besoins métier réels.

Les arbitrages de conception

Plusieurs décisions structurantes ont été prises.

S'appuyer sur Drupal plutôt que repartir de zéro

L'objectif n'était pas de développer un framework.

L'objectif était de résoudre un problème métier.

Drupal fournissait déjà la majorité des briques nécessaires.

Automatiser les tâches répétitives

Certaines opérations n'apportaient aucune valeur lorsqu'elles étaient réalisées manuellement :

activation de compte ; complétion de profil ; notifications ; redirections ; contrôles simples.

Ces tâches ont été progressivement automatisées.

Structurer les demandes autour d'un cycle de vie

Chaque demande devait posséder un état identifiable.

Sans état, aucun suivi fiable n'est possible.

Cette décision a fortement influencé l'architecture du système.

Reporter certaines fonctionnalités

Toutes les idées n'ont pas été implémentées immédiatement.

Le projet a privilégié :

la fiabilité du noyau métier ; la qualité des données ; la stabilité des workflows.

Les optimisations secondaires ont été traitées progressivement.

L'architecture mise en place

Le système repose sur plusieurs concepts principaux.

Les utilisateurs

Deux familles d'utilisateurs coexistent :

Les adhérents

Ils peuvent :

accéder à leur espace personnel ; déposer des demandes ; suivre leur avancement ; mettre à jour certaines informations. Les gestionnaires

Ils peuvent :

consulter les demandes ; les traiter ; modifier leur état ; produire des exports ; superviser l'activité. Les demandes

La demande constitue l'entité centrale du système.

Chaque demande possède :

un type ; un propriétaire ; un ensemble de données structurées ; un statut ; un historique de traitement. Les workflows

Les workflows permettent d'encadrer les transitions entre états.

Cette approche évite :

les incohérences ; les traitements incomplets ; les changements arbitraires. Les notifications

Les notifications ont été limitées aux événements réellement utiles :

inscription ; activation ; prise en compte ; récupération de mot de passe.

Cette approche permet de réduire le bruit tout en conservant l'information essentielle.

Les tableaux de bord

Deux perspectives coexistent :

Vue adhérent

L'utilisateur consulte :

ses demandes ; leur état ; les actions éventuelles à réaliser. Vue administration

Les gestionnaires disposent :

de listes filtrables ; d'outils de recherche ; de mécanismes d'export ; d'une visibilité globale. Les difficultés rencontrées Formaliser un métier implicite

La principale difficulté n'était pas technique.

Elle consistait à expliciter des règles qui existaient uniquement dans les habitudes de travail.

Transformer ces pratiques en logique métier exploitable a nécessité plusieurs itérations.

Gérer les droits

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

Le système a donc nécessité un travail important autour :

des rôles ; des permissions ; des contrôles d'accès. Maintenir la qualité des données

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

Les formulaires ont progressivement été enrichis avec :

validations ; champs obligatoires ; listes de choix ; règles métier. Faire évoluer les campagnes

Certaines demandes, notamment liées à l'estivage, évoluent régulièrement.

Le système devait rester suffisamment flexible pour intégrer :

de nouvelles résidences ; de nouvelles villes ; de nouvelles périodes ; de nouvelles règles de sélection. Améliorer l'expérience utilisateur

La plateforme a d'abord été conçue pour fonctionner correctement.

L'amélioration de l'expérience utilisateur est devenue un chantier distinct :

simplification du parcours ; refonte des pages publiques ; clarification des formulaires ; amélioration des messages utilisateur. Les résultats observables

Plusieurs bénéfices concrets sont apparus.

Une meilleure traçabilité

Chaque demande est désormais identifiable, consultable et suivable.

Une réduction des opérations manuelles

Les tâches répétitives ont été progressivement automatisées.

Une meilleure qualité des données

Les formulaires structurés produisent des informations plus cohérentes.

Une visibilité accrue

Les gestionnaires disposent désormais d'une vue consolidée de l'activité.

Un cycle de traitement plus lisible

Les adhérents comprennent mieux où se situe leur demande dans le processus.

Ce que je ferais différemment aujourd'hui

Plusieurs choix seraient conservés :

Drupal comme socle ; architecture hybride configuration + spécifique ; modélisation autour des demandes.

D'autres seraient probablement renforcés :

formalisation des workflows dès le démarrage ; 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.

L'expérience montre qu'un système métier évolue constamment.

Préparer cette évolution est souvent plus important que répondre parfaitement au besoin du jour.

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 ; les workflows sont explicites ; les responsabilités sont définies ; les données sont structurées ; les règles sont traçables ; le système reste maintenable.

Drupal s'est révélé particulièrement efficace lorsqu'il a été utilisé comme plateforme métier et non comme simple CMS.

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

Il a consisté à transformer un ensemble de pratiques dispersées en un système cohérent capable de soutenir durablement l'activité administrative de l'organisation.