Modélisation système de notre produit

• Suivre les actions de l’utilisateur à la trace
• Voir la partie cachée de l’iceberg
• L’architecture, ou les fondations à ne pas négliger
• Une vision d’ensemble à la fois précise et synthétique
• Ressources

Lorsque nous rédigeons la documentation de notre produit — qu’il s’agisse du PRD, des spécifications techniques ou même des pages destinées aux utilisateurs — nous nous retrouvons souvent face à des dizaines de pages denses et difficiles à maintenir. Et au final, peu de monde les lisent réellement jusqu’au bout.

L’adage est connu : « une image vaut mille mots ». Pourtant, dans le monde du produit et de la technique, nous avons trop souvent abandonné les représentations graphiques au profit de longs paragraphes. Il existe une solution, mais elle a mauvaise presse, chez les juniors. Nous associons l’UML (Unified Modeling Language) à des cours rigides et académiques. Pourtant, ses diagrammes — cas d’usage, séquence, états, classes — restent parmi les outils les plus efficaces pour communiquer, tant entre humains qu’avec une IA.

Ils permettent de rendre visibles l’organisation d’une application, les enchaînements d’actions des utilisateurs et tout ce qu’ils entraînent techniquement. Et surtout, ils nous obligent à penser le système dans son ensemble, plutôt que de rester collés à la surface visible.

Nous allons illustrer cela avec Manna, une application développée par ma femme avec l’aide de ChatGPT et de Claude Code. Elle propose une série de mini-jeux conçus pour faciliter l’apprentissage de la Bible. Elle intègre un système d’expérience qui récompense la progression du joueur, ainsi qu’un classement mondial.

À travers cet exemple concret, nous verrons comment les schémas nous aident à ne rien laisser dans l’ombre.

§Suivre les actions de l’utilisateur à la trace

Lorsque nous décrivons chaque parcours utilisateur, nous finissons vite par repérer des motifs qui se répètent : l’utilisateur doit être connecté pour certaines actions, pas pour d’autres ; il doit choisir un mode avant de jouer ; il gagne de l’expérience seulement s’il termine une session ; etc.

Si nous restons uniquement sur les parcours narratifs (les « user stories »), nous prenons le risque de dupliquer ces actions récurrentes à chaque fois. Le diagramme de cas d’usage est alors bien plus adapté : il permet de montrer qu’un même chemin peut être une alternative, une inclusion ou une extension d’un autre.

Sans représentation claire des actions et de leurs relations, nous multiplions les descriptions, nous oublions des cas limites et nous finissons par réinventer la roue à chaque nouvelle fonctionnalité.

Un diagramme de cas d’usage place au centre le système et autour les acteurs (le joueur dans le cas de Manna). Chaque ovale représente une intention de l’utilisateur. Les flèches montrent les inclusions (« cela fait forcément partie de… ») et les relations entre acteurs et actions.

Ici par exemple, nous nous concentrons uniquement sur le joueur et sur ce qui touche réellement au jeu et à l’expérience :

Nous voyons immédiatement que « Gagner de l’XP » n’est pas une action isolée : elle est incluse dans le fait de jouer une session. Nous évitons ainsi de la redécrire ailleurs. Ainsi, chaque nouveau parcours doit être confronté à l’existant : nous voyons ainsi quelles sont les extensions, les réutilisations, et nous pouvons anticiper ce qui peut casser.

Après avoir représenté l’enchaînement des actions de l’utilisateur, il faut en voir le cheminement au sein de l’application.

§Voir la partie cachée de l’iceberg

Derrière chaque action de l’utilisateur se trouvent de nombreuses briques invisibles : cache, base de données, calculs côté serveur, vérifications de sécurité… Tant que l’application reste légère, ces éléments passent souvent inaperçus. Mais dès que la charge augmente, ils deviennent critiques.

Le parcours utilisateur et l’interface constituent la partie visible de l’iceberg. Toute l’infrastructure qui rend ces actions possibles en constitue la partie cachée, et c’est souvent là que se cachent les mauvaises surprises.

Sans représentation formelle des échanges, nous découvrons trop tard les goulots d’étranglement : une requête trop fréquente, un calcul trop lourd côté client, une absence de validation serveur… Le diagramme de séquence montre, dans l’ordre chronologique, les messages échangés entre les acteurs et les composants du système. Il rend visibles la latence, les appels successifs et les points de friction.

Voici ce qui se passe réellement lorsqu’un joueur lance un QCM et termine sa session :

Nous constatons immédiatement que le calcul de l’XP se fait côté serveur (et non pas uniquement dans le client). C’est une décision volontaire : elle protège contre la triche et prépare l’application à une charge plus importante.

En passant par une représentation formelle des séquences, nous pouvons anticiper les goulots d’étranglement : « Si 10 000 joueurs jouent en même temps, où le système risque-t-il de saturer ? » Le schéma devient un outil de diagnostic proactif, pas seulement descriptif.

§L’architecture, ou les fondations à ne pas négliger

Lorsque l’application se complexifie, modéliser la séquence des événements ne suffit plus. Les données se multiplient, les doublons apparaissent, les responsabilités se brouillent. Il devient indispensable de visualiser la structure « à plat » pour repérer les erreurs subtiles qui ont pu s’y glisser.

Sans vue d’ensemble de l’architecture et du cycle de vie des objets, nous finissons par créer des incohérences : une même information stockée à deux endroits, des transitions d’état impossibles, des classes qui portent trop de responsabilités.

Pour cela, nous pouvons utiliser d’une part le diagramme d’états pour décrire le cycle de vie d’un objet (comme une partie de Manna), et le diagramme de classes, montrant les données et leurs relations – sans entrer dans le code.

Voici le cycle de vie d’une partie dans Manna :

Nous voyons clairement les transitions autorisées. Une partie abandonnée ne peut pas générer d’XP, tandis qu’une session terminée passe obligatoirement par la mise à jour de la progression avant de revenir au menu.

Voici maintenant la structure des données :

Ce schéma rend visibles les relations essentielles : un utilisateur joue plusieurs sessions, une session contient des réponses, chaque réponse pointe vers une question, etc. Nous évitons ainsi les doublons et les couplages involontaires.

Lorsque nous travaillons avec l’IA, nous pouvons lui demander de maintenir un schéma d’architecture à jour, pour pouvoir le diagnostiquer à chaque instant. Ce peut être un moyen de valider les choix, et éventuellement de repérer ce qui menace la pérennité du produit.

§Une vision d’ensemble à la fois précise et synthétique

L’une des limites récurrentes des IA tient à la taille du contexte. Même si les fenêtres de contexte grandissent, l’intégralité du code source d’une application n’y rentre jamais complètement. Et même avec une maîtrise parfaite du code, l’IA peut passer à côté de ce qui ne se trouve pas dans le code, mais dans l’infrastructure ou dans les règles métier implicites.

Maintenir à jour nos schémas nous permet de conserver une vision d’ensemble claire. Que le « chef d’orchestre » soit humain ou IA, cette vision reste primordiale pour garantir la cohérence du système.

Les schémas agissent comme un pont entre le produit et la technique. Ils forcent le responsable produit à comprendre le modèle de données et le cycle de vie des appels système. Ils permettent aussi de communiquer efficacement avec les agents IA : un schéma bien conçu vaut souvent bien plus que mille tokens de description textuelle.

Enfin, ils restent un excellent outil de documentation publique. Avec un peu de soin, un diagramme austère peut devenir une illustration claire et attrayante qui montre au joueur, en un coup d’œil, le chemin qu’il peut suivre dans Manna — de son besoin jusqu’au résultat de son action.

Les cas d’usages nous empêchent de dupliquer les parcours, tandis que les diagrammes de séquence nous montrent ce qui se passe vraiment sous la surface. Enfin, les diagrammes d’états et de classes nous obligent à garder des fondations saines. Ensemble, ils nous donnent un langage commun, précis et synthétique, pour construire des produits plus robustes… et pour travailler plus intelligemment avec l’IA.

Si vous souhaitez découvrir Manna en avant-première, vous pouvez rejoindre la bêta en ligne dès maintenant sur Bible Duo Game – la plateforme de Manna. Et pour participer à la bêta fermée de l’application Android, vous pouvez me contacter.

§Ressources

• UML Distilled, de Martin Fowler
• UML 2.5 par la pratique, de Pascal Roques
• The Unified Modeling Language Reference Manual, de James Rumbaugh, Ivar Jacobson et Grady Booch

NB : pour les curieux, j’ai généré mes diagrammes UML à l’aide de Gemini, en lui précisant le même style que pour mes bannières… Le plus dur était de maintenir la rigueur de l’UML, mais si vous laissez les diagrammes UML par défaut, notez que la syntaxe « mermaid » est nativement supporté par la plupart des IA (testés avec Grok et Copilot en particulier) – et donc sans risque d’incohérence.