Des projets réels.
Des complexités réelles.
Ces cas ne décrivent pas des réussites. Ils documentent des complexités traversées — et ce qu'elles ont produit.
Des règles métier dispersées, transformées en architecture partagée.
Une convergence SI multi-acteurs, sans interrompre les opérations.
L'autre côté du miroir — ce que deviennent les specs en delivery.
Une modernisation globale du système d'information, déployée sur deux fronts — un espace privé pour les avocats, un back-office pour les gestionnaires — avec un objectif central : dématérialiser et standardiser les processus pour un parcours fluide de bout en bout, en facilitant les échanges entre avocats et gestionnaires.
Une architecture existante, à moderniser de bout en bout.
Le système reposait sur une architecture fonctionnelle déjà en place, mais construite autour de dossiers papier et d'échanges manuels entre avocats et gestionnaires. La modernisation visée touchait l'ensemble du SI — dématérialiser les démarches, standardiser les processus, fluidifier un parcours qui restait encore largement administratif.
Standardiser des processus denses, sans perdre en fluidité.
Éligibilité, mise en relation, suivi de dossier, clôture — chaque domaine fonctionnel portait sa propre densité de processus, ses propres exceptions, ses interactions spécifiques entre avocats et gestionnaires. Le défi n'était pas de partir de rien, mais de standardiser un ensemble de parcours existants pour qu'ils deviennent fluides de bout en bout, sans perdre la richesse fonctionnelle déjà en place.
Structurer et formaliser, domaine par domaine.
Série d'ateliers métier, domaine par domaine, pour préciser chaque processus à dématérialiser et arbitrer les points de friction entre avocats et gestionnaires. Story Mapping pour organiser les parcours en architecture lisible. Conception détaillée de l'ensemble des User Stories Enterprise Grade, avec critères d'acceptation vérifiables — un référentiel directement exploitable par les équipes de développement.
D'un parcours administratif à une expérience fluide de bout en bout.
Les démarches qui passaient par des échanges manuels et des dossiers papier sont devenues des parcours numériques standardisés. Les User Stories Enterprise Grade, avec leurs critères d'acceptation vérifiables, ont donné aux équipes de développement un référentiel unique, directement exploitable.
Un parcours dématérialisé, standardisé, et un produit prêt à construire.
L'ensemble du périmètre fonctionnel — espace avocat et back-office gestionnaire — formalisé en User Stories Enterprise Grade, directement exploitables pour le développement.
En tant qu'avocat, je souhaite pouvoir m'inscrire au volontariat directement depuis mon espace privé, afin de ne plus avoir à constituer un dossier papier comme c'est le cas actuellement.
Un programme de migration et d'unification du système d'information pour l'ensemble des caisses historiquement décentralisées — mené en parallèle d'un projet réglementaire à échéance imposée, la DSN, sans interrompre les opérations en cours.
Un réseau national de caisses, chacune avec son histoire propre.
CIBTP France fonctionnait comme un réseau de caisses organisées de façon décentralisée, chacune ayant développé ses pratiques et ses systèmes sur plusieurs décennies. Cette organisation avait du sens historiquement — mais elle devenait un obstacle face à une transformation qui devait désormais converger vers un système d'information unique.
Deux trajectoires à mener de front, sans qu'elles se percutent.
Le programme de migration et d'unification du SI suivait sa propre logique, sur son propre calendrier. En parallèle, le projet DSN imposait une échéance réglementaire externe, avec son impact propre sur les processus métier de chaque caisse. Ce type de programme ne se pilote pas avec des spécifications uniquement — il fallait que les deux trajectoires avancent sans se neutraliser, ni se télescoper sur les ressources ou le calendrier.
Sécuriser les deux trajectoires, sans sacrifier l'une à l'autre.
Structuration des besoins de chaque caisse pour le programme de migration, coordination transverse entre des acteurs aux pratiques historiquement différentes, mise en place d'une gouvernance avec pilotage dédié — capable d'absorber en parallèle l'échéance réglementaire DSN sans qu'elle ne vienne percuter le calendrier de migration. Chaque arbitrage documenté au moment où il est pris — l'alignement des acteurs n'était pas un objectif secondaire, c'était la condition pour tenir les deux calendriers.
Deux programmes tenus de front, sans perte de cohérence sur aucun des deux.
Le programme de migration a avancé sur 24 mois sans que le projet DSN, mené en parallèle, ne crée de rupture sur l'un ou l'autre calendrier. Chaque acteur du réseau savait pourquoi telle décision avait été prise, même s'il n'était pas dans la salle au moment où elle l'a été — la traçabilité avait remplacé la dépendance à la mémoire individuelle.
Une transformation nationale menée sans perte de cohérence.
Le programme de migration mené à son terme, l'échéance réglementaire DSN tenue en parallèle, l'alignement maintenu sur la durée entre toutes les caisses du réseau — chaque arbitrage documenté et tracé jusqu'à son origine dans les besoins initiaux.
Concevoir une spécification est un exercice. Savoir ce qu'elle devient une fois entre les mains des équipes de développement en est un autre — c'est sur cet écart qu'AYTIS a construit sa valeur.
Des spécifications qui se lisaient bien — et se comprenaient mal.
L'environnement projet était structuré, les acteurs nombreux. Mais l'écart entre ce qui était écrit dans les spécifications et ce que les équipes de développement en comprenaient restait invisible à la rédaction — ce sont les contraintes concrètes du delivery, pas la qualité apparente du document, qui révélaient l'imprécision.
L'autre côté du miroir — la réalité du delivery au quotidien.
L'intervention a couvert trois phases distinctes : conception, delivery, retour d'expérience. Cette continuité a permis d'observer directement les contraintes concrètes des équipes de développement — leurs délais, leurs arbitrages techniques, ce qui les force à interpréter une spécification plutôt que de la suivre. Une observation que peu de consultants en structuration mènent jusqu'au bout.
La connaissance précise de l'autre côté du miroir.
Cette intervention a donné à AYTIS quelque chose que peu de consultants en structuration possèdent : savoir exactement ce que deviennent les spécifications entre les mains des équipes qui construisent, et quelles contraintes les forcent à interpréter plutôt qu'à exécuter. Cette connaissance se traduit directement dans la conception : des spécifications pensées pour être suivies, pas seulement lues — et cela change durablement la façon de concevoir chaque livrable, sur chaque mission suivante.
Des spécifications qui restent valables une fois confiées à l'équipe de développement.
La capacité à concevoir des spécifications qui restent exploitables une fois confiées aux équipes de développement — en connaissant les deux faces du processus, celle de la rédaction et celle de la construction.
Trois contextes différents.
Une même conviction.
Comprendre avant de structurer. Structurer avant de concevoir. Documenter chaque décision pour qu'elle reste retrouvable.
La complexité était réelle, pas théorique
Acteurs multiples, règles non-documentées, opérations à ne pas interrompre. Aucun de ces trois projets ne pouvait se résoudre par un template.
La structuration a précédé l'exécution
Dans les trois cas, le temps passé à comprendre et structurer en amont a évité des révisions coûteuses en aval.
Chaque livrable restait exploitable
Règles métier, décisions de gouvernance, spécifications — conçus pour être utilisés directement, pas seulement pour être lus.
Votre projet a ses propres complexités.
Parlons-en.
Prenons le temps de comprendre votre contexte avant d'envisager quoi que ce soit.
Comprendre·Structurer·Concevoir