Une licence indisponible. Un planning à tenir. 30 000 euros économisés. Voici comment une équipe agile transforme un blocage en valeur livrée.
Le scénario que personne ne veut vivre
Janvier 2026. Le projet démarre.
L'objectif : moderniser la gestion des contrats collectifs Santé & Prévoyance pour un acteur majeur de la mutuelle santé. Remplacer une gestion 100 % manuelle par un outil IHM centralisé, traçable, connecté au Datahub. Trois lots, des sprints de deux semaines, une roadmap jusqu'en T3 2026.
Tout est cadré. L'équipe est en place : Product Owner, Data Engineer, CTO, sponsors côté client. La gouvernance est posée. Les cérémonies agiles sont planifiées.
Et là, dès le démarrage : la licence PIMCORE, identifiée comme prérequis central pour toute l'ingestion de données, n'est pas disponible.
Pas de licence. Pas d'environnement. Pas de base de travail.
Dans un projet en cascade classique, c'est le blocage total. On attend. On escalade. On décale le planning. On revient en comité de pilotage avec une slide rouge.
Ce n'est pas ce qui s'est passé.
Ce que l'équipe a fait à la place
L'équipe Bomzai a développé un script d'ingestion de données sur mesure pour contourner la dépendance à la licence.
Pas un workaround bricolé. Un outil fonctionnel, en production, capable d'ingérer les données nécessaires au démarrage du lot 1 sans passer par PIMCORE.
Résultat : le rythme des sprints de deux semaines est maintenu. Le planning n'est pas décalé. Le client n'a pas à financer une licence qu'il n'utilise pas encore, ni à attendre qu'elle soit disponible pour commencer à voir de la valeur.
30 000 euros économisés. Planning tenu. Valeur livrée dès le premier sprint.
Ce chiffre mérite qu'on s'y arrête. Pas parce qu'il est impressionnant en soi, mais parce qu'il illustre exactement ce que l'agilité est censée produire : une équipe qui absorbe un obstacle et continue à créer de la valeur, sans attendre la permission du prérequis.
Projet Bomzai - Outil de gestion contrat collectif Santé & Prévoyance, 2026
Ce que le Manifeste Agile dit vraiment là-dessus
Le Manifeste Agile a 24 ans. On en parle beaucoup. On l'applique moins souvent qu'on ne le pense.
Voici deux de ses principes fondateurs, lus à la lumière de ce projet :
Principe 2 — "Accueillez favorablement les changements de besoins, même tard dans le développement."
La non-disponibilité d'une licence n'est pas un changement de besoin au sens strict. C'est une contrainte externe, non anticipée, qui modifie le terrain de jeu dès le départ. L'esprit du principe est le même : ne pas traiter l'obstacle comme une anomalie qui invalide le plan, mais comme une donnée que l'équipe intègre et contourne.
Principe 11 — "Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées."
C'est exactement ce qui s'est passé. Personne n'a demandé à l'équipe de développer un script d'ingestion. Ce n'était pas dans le backlog initial. L'équipe a vu le problème, a identifié une solution technique, et l'a mise en oeuvre. Sans escalade inutile. Sans attendre un go en comité.
C'est ça, une équipe auto-organisée. Pas une équipe qui remplit des colonnes Jira proprement.
L'agilité réelle vs l'agilité de façade
Il faut être honnête sur ce point.
Beaucoup de projets se disent agiles parce qu'ils font des stand-ups quotidiens, des rétrospectives le vendredi et des sprint reviews avec un PowerPoint. C'est la forme. Ce n'est pas le fond.
L'agilité réelle, c'est ce qui se passe quand le prérequis disparaît au sprint 1.
Est-ce que l'équipe attend ? Est-ce qu'elle escalade immédiatement en se défaussant sur la contrainte ? Ou est-ce qu'elle pivote, trouve une solution, et maintient le cap sur la valeur à livrer ?
Le Manifeste Agile place "répondre au changement" au-dessus de "suivre un plan". Pas parce que les plans sont inutiles. Le kick-off de ce projet avait une roadmap précise, des jalons clairs, une gouvernance documentée. Mais parce que la capacité à s'adapter est plus précieuse que la capacité à respecter un plan dans un monde qui ne change pas.
Les projets Data & IA vivent dans un monde qui change. Les licences ne sont pas disponibles. Les sources de données ne sont pas prêtes. Les filtres métiers sont plus complexes que prévu. Les sponsors changent de priorité. Ce n'est pas l'exception. C'est la norme.
Ce que ça demande concrètement à une équipe
Adapter une équipe à réagir comme celle de ce projet ne se décrète pas. Ça se construit.
01 — Une culture du "livrer quand même"
L'objectif du sprint ne change pas parce qu'un outil n'est pas disponible. On cherche un chemin alternatif. S'il n'existe pas, on le construit. La valeur à livrer reste la boussole.
02 — La proximité technique du Product Owner
Sur ce projet, la gouvernance intégrait le PO dans les sprint plannings et les revues. Un PO qui comprend les contraintes techniques valide rapidement une solution de contournement au lieu d'attendre une réunion de comité.
03 — Des sprints courts comme filets de sécurité
Deux semaines. Pas quatre, pas six. Les sprints courts forcent à trancher vite. Si une solution ne fonctionne pas, on le sait en deux semaines, pas en deux mois. L'erreur reste contenue. L'apprentissage est immédiat.
04 — La confiance comme infrastructure
Le client n'a pas demandé un rapport d'incident quand la licence PIMCORE s'est révélée indisponible. Il a fait confiance à l'équipe. Cette confiance ne s'acquiert pas par défaut. Elle se gagne sprint après sprint, livraison après livraison.
Le risque qui était dans le registre dès le départ
Un dernier point, pas anodin.
Au kick-off de janvier 2026, le registre des risques indiquait :
R1 · Probabilité 5/5 · Sévérité 5/5 — "Difficulté d'installer PIMCORE via Docker en local." Moyen de mitigation : à gérer en phase init.
Ce risque était classé critique. L'équipe l'a géré. En phase init. Exactement comme prévu, mais pas de la façon prévue.
C'est aussi ça, la gestion de risque agile. Ne pas gérer le risque en espérant qu'il ne se matérialise pas. Le gérer en construisant la capacité à répondre quand il se matérialise.
Ce qu'on retient de ce projet
L'agilité n'est pas une méthodologie de gestion de projet. C'est une posture face à l'incertitude.
Sur ce projet, cette posture a produit un résultat mesurable : 30 000 euros économisés, un planning tenu, une équipe qui a transformé un blocage en décision technique en moins d'un sprint.
Ce n'est pas de la chance. C'est le résultat d'une équipe qui a internalisé ce que le Manifeste Agile dit depuis 2001 : la valeur ne vient pas du respect du plan. Elle vient de la capacité à s'adapter quand le plan rencontre la réalité.
Bomzai accompagne ses clients de la stratégie Data & IA jusqu'à la mise en production. Partenaire opérationnel, pas prestataire ponctuel.