Introduction – La modélisation des données, colonne vertébrale oubliée

Dans les projets IT menés en mode agile, les efforts se concentrent naturellement sur ce qui est visible, tangible, démontrable rapidement : l’interface utilisateur, les parcours métier, les retours immédiats des parties prenantes. La donnée, elle, passe souvent au second plan — perçue comme une simple “conséquence technique” à traiter plus tard, une fois les écrans validés.

Pourtant, la donnée est ce qui perdure. L’interface changera encore, les technologies aussi. Mais les structures de données, elles, sont appelées à durer. Une mauvaise modélisation ou une absence de vision d’ensemble laissera des traces longtemps après que les sprints seront terminés.

Ce paradoxe – vouloir construire vite sur des fondations qu’on ne prend pas le temps de définir – n’est pas simplement un écueil méthodologique. Il révèle un déficit plus profond, un manque de préparation structurelle au niveau de l’organisation elle-même : l’absence d’un modèle de données d’entreprise ou, à tout le moins, d’une vision partagée des objets métiers centraux.

Dans cet article, je propose de mettre en lumière ce paradoxe, d’en expliquer les racines, et surtout, de poser une orientation concrète pour y remédier sans sacrifier la dynamique des projets agiles.

Le paradoxe de l’agilité : rapide, mais sans fondation

L’approche agile valorise la livraison rapide de valeur, l’expérimentation, et l’adaptation continue. On découpe les fonctionnalités en user stories, on enchaîne les sprints, et on vise des incréments tangibles à chaque itération. Le succès est souvent mesuré à la vitesse à laquelle on peut livrer quelque chose de visible à l’utilisateur.

Dans ce contexte, la modélisation des données semble en décalage. Elle demande du recul, de la stabilité, une vision d’ensemble. Elle nécessite de poser des questions transverses, de synchroniser les points de vue métiers, de formaliser des concepts durables. Tout ce que l’agilité, dans son application la plus opérationnelle, tend à contourner pour éviter l’inertie.

Résultat : on remet la modélisation à plus tard. On se dit qu’on ajustera le schéma de données au fil de l’eau, que l’architecture évoluera avec les besoins. En théorie, c’est séduisant. En pratique, on découvre souvent trop tard que certaines décisions — prises à la hâte ou non prises du tout — compromettent l’évolutivité, la cohérence ou la qualité de l’application.

Et c’est là que le paradoxe éclate : vouloir aller vite sans fondation solide, c’est prendre le risque de construire un édifice fragile. Et quand les premiers étages sont déjà en place, il devient très difficile — voire impossible — de reprendre les fondations sans tout ébranler.

Quand le paradoxe apparaît, c’est que le mal est déjà fait

Dans de nombreux projets auxquels j’ai participé, le constat est toujours le même : ce n’est qu’en cours de route que l’on réalise qu’il manque quelque chose de fondamental. Les objets métiers sont flous, les règles de gestion implicites, et les structures de données se contredisent d’un sprint à l’autre. On cherche alors à clarifier… mais trop tard. À ce stade, on ne résout pas un oubli, on subit une lacune structurelle.

Ce genre de situation ne relève pas d’un simple défaut de cadrage projet. Il traduit un manque d’anticipation au niveau organisationnel. Le problème n’est pas localisé dans l’équipe agile : il est enraciné dans l’absence d’un modèle conceptuel d’entreprise — ou, à défaut, d’un cadre commun structurant les grands objets métiers de l’organisation.

Sans cette vision partagée, chaque projet devient une tentative isolée de redéfinir les concepts de base : qu’est-ce qu’un client ? une commande ? un produit ? un bénéficiaire ? On réinvente, on adapte, parfois on bricole… Mais on le fait sans socle stable, ce qui multiplie les incohérences entre applications et compromet la qualité des données dans le temps.

En réalité, lorsque l’équipe s’aperçoit du paradoxe, le mal est déjà fait : le projet hérite d’un vide que l’organisation n’a jamais pris le temps de combler.

À ce stade, deux chemins : corriger ou continuer

Lorsque les incohérences de structure apparaissent en pleine phase de développement, l’organisation se retrouve face à un dilemme : reprendre les fondations ou avancer malgré tout. La première option consisterait à suspendre temporairement le projet, clarifier les concepts, poser un modèle robuste, puis reprendre sur des bases assainies.

C’est une décision raisonnable sur le plan technique, mais rarement envisagée dans les faits. Les engagements ont été pris, les budgets engagés, les plannings communiqués. L’inertie du projet l’emporte sur la rigueur méthodologique. Le pilotage par le retour sur investissement rend difficile toute remise en question profonde : il faut livrer quelque chose, même imparfait.

La suite est prévisible : on fait au mieux avec l’existant, on empile des ajustements locaux, on accepte des zones d’ombre dans la modélisation. Le projet avance en mode dégradé, avec des choix qui permettent de tenir les échéances à court terme, mais dont le coût caché — en dette fonctionnelle, complexité applicative ou qualité des données — finira par se faire sentir.

Ce que je préconise : dissocier projet agile et chantier de modélisation

Plutôt que de faire reposer la structuration des données sur les épaules d’un projet en cours, je recommande d’enclencher un travail de fond indépendant, piloté par une vision plus large que celle du périmètre applicatif immédiat.

La modélisation des données d’entreprise — qu’il s’agisse de référentiels métiers, de dictionnaires de données ou de cartographies conceptuelles — mérite un chantier dédié, inscrit dans le temps long. Ce chantier ne doit pas être conditionné par les aléas ou les délais d’un projet agile, mais porté comme un investissement stratégique de l’organisation.

Les projets IT, eux, peuvent continuer à livrer en s’appuyant sur des hypothèses temporaires, tout en sachant que des arbitrages plus structurés viendront progressivement fiabiliser le socle. Cette démarche offre un cap, même si les premières étapes doivent se faire avec les moyens du bord. L’enjeu est de ne plus confondre vitesse d’exécution et clarté structurelle.

Accepter de démarrer en mode dégradé, mais avec un cap

Il serait illusoire de vouloir figer l’ensemble du patrimoine informationnel de l’entreprise avant d’écrire la moindre ligne de code. Les projets doivent avancer, parfois dans des conditions imparfaites. Mais cela ne signifie pas qu’il faille renoncer à toute rigueur.

L’enjeu, ici, est d’assumer temporairement l’imperfection, tout en adoptant une posture proactive. Il s’agit de documenter les zones floues, d’identifier les écarts entre les visions locales, et de poser les premiers jalons d’un socle commun. Ce travail de clarification, même partiel, bénéficiera à l’ensemble des projets, pas uniquement à celui qui en paie aujourd’hui le prix fort.

C’est une démarche transverse, structurante pour l’organisation dans son ensemble. L’équipe data, l’architecte fonctionnel ou les acteurs de la gouvernance jouent alors un rôle d’éclaireurs : ils aident à donner du sens, à cartographier, à créer des ponts — sans ralentir les dynamiques locales, ni imposer une normalisation rigide. L’objectif n’est pas d’ériger une tour d’ivoire, mais de construire un langage commun au fil des projets.

Conclusion – L’agilité ne dispense pas de fondation, elle les révèle

Loin d’être la cause des difficultés liées aux données, l’agilité agit plutôt comme un révélateur. En accélérant les cycles de développement et en confrontant rapidement les livrables aux réalités métier, elle met en lumière des fragilités qui, dans des approches plus séquentielles, seraient restées masquées plus longtemps.

Ces tensions ne doivent pas être interprétées comme un défaut de la méthode, mais comme un signal clair : la donnée ne peut plus être traitée comme une variable secondaire. Elle exige une attention spécifique, en dehors du rythme imposé par les projets. Cet effort de structuration — progressif, transverse, évolutif — est la condition pour que les projets puissent s’appuyer sur un socle solide, sans avoir à le reconstruire à chaque fois.

En fin de compte, c’est en investissant dans la modélisation en dehors de l’urgence projet que l’on crée les conditions d’une véritable agilité : réactive, mais aussi durable, cohérente, et sans dette cachée.