Fondateur d'AYTIS
Qui est derrière AYTIS

Yassine Bourri

Consultant en structuration, conception et transformation des systèmes d'information

Quinze ans à voir différents projets dérailler pour les mêmes raisons. Une accumulation d'expériences, de programmes de transformation et de projets stratégiques m'a conduit à une conviction simple : les difficultés apparaissent souvent bien avant la première ligne de code.

Portrait de Yassine Bourri, fondateur d'AYTIS

Le déclic

Ce n'est pas une intuition.
C'est un schéma observé pendant quinze ans.

Chef de projet, consultant AMOA, parfois développeur — chaque rôle a montré la même chose depuis un point de vue différent. Les projets ne se grippent pas pendant le développement. Ils se grippent avant, quand le besoin n'a pas été suffisamment compris, quand les décisions ne sont pas tracées, quand les acteurs avancent sans partager la même vision.

Avoir été du côté du développement, puis du côté de la structuration, puis du côté du pilotage transverse, donne une perspective rare : celle de voir où l'imprécision d'un cadrage se paie réellement — six mois plus tard, dans le code, dans les retards, dans les arbitrages refaits deux fois.

AYTIS n'est pas né d'une intuition. Il est né de cette accumulation.

Trois points de vue · une seule observation
Côté développement

Une spec ambiguë devient un choix d'implémentation

non-validé par le métier

Côté AMOA

Une règle métier mal formalisée se découvre

en recette, jamais avant

Côté pilotage transverse

Une décision non-documentée devient une incohérence

retrouvée six mois plus tard

Trois symptômes. Une seule cause racine.

Ce que 15 ans de rôles différents ont fini par révéler
Le parcours

Trois chapitres. Une même conviction.

Trois contextes très différents. Une seule conviction qui s'est renforcée à chaque fois.

Bouygues Immobilier
2009 — 2014

Ingénieur développement, puis chef de projet back-office, puis chef de projet — trois rôles sur le même périmètre applicatif.

→ Comprendre comment les logiciels sont réellement construits.

Apprendre le delivery, de l'intérieur.

Avant de structurer un besoin, il a fallu d'abord le recevoir tel qu'il arrivait — flou, incomplet — et le transformer en code malgré tout. Développeur .NET sur les outils de gestion commerciale, puis chef de projet back-office, puis chef de projet sur la commercialisation en ligne : ce parcours ascendant à l'intérieur d'un même environnement a montré très concrètement ce que devient une spécification une fois confiée à une équipe de développement. Ce que les contraintes réelles — délais, dette technique, arbitrages de dernière minute — forcent à interpréter plutôt qu'à exécuter à la lettre.

Ce qui a été retenu

Une spécification n'a de valeur que si elle a été pensée pour celui qui va la construire — pas seulement pour celui qui la rédige.

Développement .NET Spécifications fonctionnelles Encadrement d'équipe Back-office applicatif
UCF puis CIBTP France
2014 — 2024

Responsable de portefeuille, puis chef de projet transverse sur la transformation nationale du réseau.

→ Comprendre comment transformer un système d'information à grande échelle.

Dix ans au cœur d'une transformation nationale.

Dix années qui ne se résument pas à un projet de migration. Le portefeuille couvrait simultanément plusieurs programmes — la convergence du réseau vers un système d'information unique (SIU Sirius) et la mise en conformité avec la DSN, projet réglementaire national distinct mais embarqué dans la même trajectoire — et mobilisait des responsabilités multiples : gestion de portefeuille, delivery, pilotage transverse, coordination entre métiers et DSI, homologation fonctionnelle et VSR, accompagnement des équipes dans l'adoption d'approches agiles. Cette diversité de rôles et de programmes, exercée sans jamais interrompre l'activité d'un réseau national, a construit une conviction sur la gouvernance.

Ce qui a été retenu

Sur un programme de cette ampleur, la gouvernance n'est pas une formalité administrative — c'est ce qui empêche un arbitrage non documenté de devenir une incohérence six mois plus tard.

Migration & fusion SI Gestion de portefeuille Pilotage transverse Coordination métier / DSI Homologation & VSR Approches Agile Programme DSN national Gouvernance multi-acteurs
Agence Française de l'Adoption
2021

Consultant AMOA & assistant au chef de projet, sur la refonte d'un SI métier sensible.

→ Comprendre que cadrer précède toujours consulter.

Cadrer avant de consulter le marché.

Une refonte de système d'information ne commence pas par un appel d'offres réussi. Elle commence par un cahier des charges qui dit vraiment ce dont l'organisation a besoin. Ce projet a consisté à structurer ce cadrage avec la direction et les utilisateurs avant même de solliciter des candidats — puis à organiser la sélection elle-même, ateliers et grilles d'évaluation compris.

Ce qui a été retenu

Le temps gagné en sautant l'étape de cadrage se paie toujours plus cher à la phase suivante — sous une autre forme.

Cadrage fonctionnel Cahier des charges Assistance appel d'offres
Mission en cours

→ Comprendre que les difficultés majeures sont rarement techniques — mais liées à la compréhension, aux arbitrages et à la structuration.

Ordre des Avocats de Paris (ODA / CARPA) — refonte d'un produit métier complet.

01 Système d'information unique — front avocat & back-office gestionnaire
05 Étapes de démarche, du cadrage au développement
Senior Consultant en structuration — mission de terrain, en cours

L'objectif n'était pas de moderniser quelques écrans existants. L'objectif était de repenser un produit métier complet, utilisé quotidiennement par des populations aux attentes très différentes — un front-office avocat, un back-office gestionnaire, des dispositifs réglementaires, une forte densité de règles de gestion accumulées sur plusieurs années.

La difficulté n'était pas technique. Elle se situait, comme souvent, bien avant le développement : des pratiques historiques, des règles parfois implicites, des acteurs ayant chacun leur propre vision du besoin.

L'intervention, en tant que consultant senior en structuration, a porté sur la structuration du produit cible dans son ensemble — animation des ateliers métier, cartographie des processus, Story Mapping, conception détaillée, arbitrages fonctionnels, production des User Stories, coordination des parties prenantes jusqu'à la décision produit.

Ce n'est pas un projet applicatif. C'est une transformation produit et métier — la refonte couvre un système d'information unique mais très vaste, articulé autour d'un front-office et d'un back-office étroitement imbriqués, une forte densité de parcours et de domaines métier, et une gouvernance des arbitrages qui engage l'ensemble de l'organisation.

Refonte globale du SI Front-office avocat Back-office gestionnaire Story Mapping Conception détaillée Gouvernance produit
La démarche appliquée
01 Comprendre — reconstituer la vision métier
02 Structurer — organiser les parcours et les irritants
03 Aligner — faire émerger les arbitrages structurants
04 Concevoir — produire les User Stories exploitables
05 Faire développer — sur une base déjà partagée

« Les projets ne deviennent pas difficiles lorsque le développement commence. Ils deviennent difficiles lorsque la compréhension du besoin est incomplète, lorsque les décisions ne sont pas explicitées, lorsque les acteurs ne partagent pas la même vision. »

Pourquoi AYTIS, et pourquoi maintenant

→ Pourquoi AYTIS existe, et pourquoi cette approche est différente.

Structurer avant que la complexité
ne devienne irréversible.

Quinze ans de programmes de transformation, de projets stratégiques et de delivery ont montré une même réalité, observée depuis des angles différents : un projet ne dérape pas pendant le développement — il dérape avant, lorsque le besoin reste implicite, lorsque les décisions ne sont pas tracées, lorsque les acteurs n'avancent pas alignés sur une même compréhension.

AYTIS est la structure que j'ai créée pour porter cette discipline — pas une méthode de plus à celles qui existent déjà. Elle structure ce qui précède le développement — la compréhension du besoin, l'alignement des parties prenantes, la conception de la cible — pour que le code exécute une décision claire plutôt que de la découvrir en cours de route.

C'est cette discipline, et non une intuition, qui fonde AYTIS : comprendre, structurer, concevoir — avant que la difficulté ne s'installe.

Yassine Bourri Fondateur, AYTIS
Envie d'échanger directement ?

Parlons de votre projet.

Prenons le temps de comprendre votre contexte avant d'envisager quoi que ce soit.

Parlons de votre projet Voir les cas clients

Comprendre·Structurer·Concevoir