Bienvenue sur FlowZap, l'application pour créer des diagrammes avec Rapidité, Clarté et Contrôle.

Le diagramme qui manque aux architectes IA

29/08/2026

Tags: problem-mind-map, mind-map, architecture-agentique, problem-first, flowzap

Jules Kovac

Jules Kovac

Business Analyst, Founder

Le diagramme qui manque aux architectes IA

 

Avant de concevoir un système d'IA, rendez le problème explicite.

Un client dit : « Nous avons besoin d'un agent IA pour le service client. »

Cinq minutes plus tard, quelqu'un a dessiné :

User → Agent → LLM → RAG → CRM → Human

Cela ressemble à de l'architecture. Mais ça n'en est pas. C'est une solution à un problème que personne n'a encore correctement défini.

Cette distinction compte plus que jamais en architecture IA. Produire une architecture plausible est désormais facile. N'importe quel LLM peut en générer une en quelques secondes. N'importe lequel. Pourtant, comprendre ce que nous devrions réellement construire reste difficile. C'est pourquoi je pense que les architectes IA devraient parfois commencer par un diagramme qui n'est pas du tout un diagramme d'architecture.

Commencez par une mind map de problème.

 

 

Le problème vient avant l'architecture

L'idée de la conception axée sur le problème n'est pas nouvelle. De plus en plus, les guides de conception IA insistent sur la compréhension du problème, la définition des critères de succès, et le choix d'une solution seulement une fois l'espace problème clarifié.

Mais il y a un fossé gênant entre dire « Définissez d'abord le problème » et le faire réellement.

  • À quoi ressemble la définition du problème ?
  • Où la capturez-vous ?
  • Comment la révisez-vous avec les parties prenantes ?
  • Comment rendez-vous l'incertitude visible ?

Et surtout : Comment cette définition du problème survit-elle quand on passe à l'architecture ?

Une mind map de problème peut apporter une réponse concrète. Ce n'est pas un énième document d'exigences. Ce n'est pas une énième liste de contrôle. C'est un modèle visuel de l'espace problème.

 

 

Espace problème avant espace solution

Je trouve utile de concevoir l'architecture IA comme une progression entre deux espaces.

 

Espace problème

De quoi s'agit-il ?

  • Décisions
  • Données
  • Politiques
  • Acteurs
  • Systèmes
  • Contraintes
  • Risques
  • Inconnues

 

Espace solution

Que devrions-nous construire ?

  • Workflows
  • Agents
  • Outils
  • Intégrations
  • Garde-fous
  • Contrôles humain-dans-la-boucle
  • Architecture

L'erreur n'est pas de dessiner des diagrammes d'architecture. L'erreur est de sauter directement à eux. Une mind map de problème vous donne un lieu pour explorer le problème avant de vous engager dans une solution.

 

 

Qu'est-ce qu'une mind map de problème ?

Une mind map de problème est un inventaire visuel de l'espace problème. Elle répond à une question d'une simplicité trompeuse :

De quoi s'agit-il exactement, et qu'est-ce qui le touche ?

C'est ce qui la distingue des diagrammes que nous utilisons habituellement pour concevoir des systèmes.

  • Les diagrammes de workflow décrivent ce qui doit se passer.
  • Les diagrammes de séquence décrivent qui interagit avec qui, et quand.
  • Les diagrammes d'architecture décrivent comment le système est assemblé.

Une mind map de problème décrit le territoire que ces conceptions sont censées adresser.

Elle capture des éléments tels que :

  • décisions
  • données
  • politiques
  • acteurs
  • systèmes existants
  • contraintes
  • risques
  • questions ouvertes

Et il y a une discipline utile derrière : Utilisez des noms avant des verbes.

Vous ne concevez pas encore le système. Vous établissez le vocabulaire du problème.

 

 

Commencez par une décision de crédit

Imaginez qu'on vous demande de concevoir un système d'IA qui aide à décider si un client devrait recevoir du crédit. La tentation naturelle est de commencer à discuter d'agents, de modèles, de récupération, d'intégrations et d'automatisation. Au lieu de cela, mettez le problème réel au centre :

Décider d'accorder ou non un crédit

Ensuite, cartographiez ce qui l'entoure.

Voici l'exemple complet utilisé pour générer la mind map ci-dessus :

 

credit_decision { # Credit decision
  n1: circle label:"Decide whether to grant credit"
  n2: rectangle label:"Decisions"
  n3: rectangle label:"Data"
  n4: rectangle label:"Policies"
  n5: rectangle label:"Actors"
  n6: rectangle label:"Risks"
  n7: rectangle label:"Constraints"
  n8: rectangle label:"Open questions"
  n9: rectangle label:"Approve / decline"
  n10: rectangle label:"Amount & rate"
  n11: rectangle label:"Human review"
  n12: rectangle label:"Client history"
  n13: rectangle label:"Income & contracts"
  n14: rectangle label:"External score"
  n15: rectangle label:"Thresholds"
  n16: rectangle label:"Exceptions"
  n17: rectangle label:"Regulations"
  n18: rectangle label:"Who has authority?"
  n19: rectangle label:"Customer"
  n20: rectangle label:"Credit officer"
  n21: rectangle label:"Supervisor"
  n22: rectangle label:"Compliance"
  n23: rectangle label:"Hallucination"
  n24: rectangle label:"Bias"
  n25: rectangle label:"Privacy"
  n26: rectangle label:"Liability"
  n27: rectangle label:"Audit trail"
  n28: rectangle label:"Explainability"
  n29: rectangle label:"GDPR"
  n30: rectangle label:"Where do thresholds live?"
  n31: rectangle label:"Dispute: who answers?"
  n32: rectangle label:"Review margin?"

  n1.handle(right) -> n2.handle(left)
  n1.handle(bottom) -> n3.handle(top)
  n1.handle(top) -> n4.handle(bottom)
  n1.handle(left) -> n5.handle(right)
  n1.handle(right) -> n6.handle(top)
  n1.handle(bottom) -> n7.handle(left)
  n1.handle(top) -> n8.handle(right)
  n2.handle(right) -> n9.handle(left)
  n2.handle(bottom) -> n10.handle(top)
  n2.handle(top) -> n11.handle(bottom)
  n3.handle(right) -> n12.handle(left)
  n3.handle(bottom) -> n13.handle(top)
  n3.handle(top) -> n14.handle(bottom)
  n4.handle(right) -> n15.handle(left)
  n4.handle(bottom) -> n16.handle(top)
  n4.handle(top) -> n17.handle(bottom)
  n4.handle(left) -> n18.handle(right)
  n5.handle(right) -> n19.handle(left)
  n5.handle(bottom) -> n20.handle(top)
  n5.handle(top) -> n21.handle(bottom)
  n5.handle(left) -> n22.handle(right)
  n6.handle(right) -> n23.handle(left)
  n6.handle(bottom) -> n24.handle(top)
  n6.handle(top) -> n25.handle(bottom)
  n6.handle(left) -> n26.handle(right)
  n7.handle(right) -> n27.handle(left)
  n7.handle(bottom) -> n28.handle(top)
  n7.handle(top) -> n29.handle(bottom)
  n8.handle(right) -> n30.handle(left)
  n8.handle(bottom) -> n31.handle(top)
  n8.handle(top) -> n32.handle(bottom)
}

 

Remarquez ce qui manque délibérément.

Il n'y a ni Agent, ni LLM, ni RAG, ni MCP, aucune architecture. Et c'est le but.

La carte ne cherche pas à répondre : « Comment devrions-nous construire le système ? »

Elle cherche à répondre : « Qu'essayons-nous exactement de résoudre ? »

 

 

Cinq étapes pour construire une mind map de problème

 

1. Mettez le problème au centre

C'est la décision la plus importante. Ne mettez pas la technologie au centre.

Évitez « Agent IA pour les sinistres », ou « Service client automatisé ». Ce sont des solutions déguisées en problèmes. Décrivez plutôt le résultat, la décision ou le problème d'affaires :

  • Décider d'accorder ou non un crédit
  • Résoudre les demandes de support client
  • Réduire de 30 % les tickets mal acheminés

La différence est subtile, mais importante. Dès qu'une technologie est au centre, la carte tend à devenir une justification de cette technologie. Une carte centrée sur le problème garde la solution ouverte.

 

 

2. Cartographiez ce qui touche le problème

Établissez maintenant le vocabulaire.

Un point de départ utile :

  • Décisions — Qu'est-ce qui doit être décidé ?
  • Données — Quelles informations existent ?
  • Politiques — Qu'est-ce qui régit les décisions ?
  • Acteurs — Qui est impliqué ?
  • Systèmes — Qu'est-ce qui existe déjà ?

Utilisez un concept par nœud. Au lieu d'écrire : « L'agent devrait récupérer les informations client depuis le CRM », écrivez :

  • Client
  • CRM
  • Historique client

C'est cartographier le territoire avant de décider comment le parcourir. Cette étape crée souvent la première information utile :

  • La branche « connaissances » peut être mince.
  • Les politiques peuvent être dispersées entre plusieurs sources.
  • Personne ne s'accorde peut-être sur le propriétaire réel d'une décision.

Ce n'est pas un problème avec la carte. C'est la carte qui fait son travail.

 

 

3. Cartographiez ce qui peut tuer la solution

Les systèmes réels ne fonctionnent pas sur le chemin heureux. Ajoutez donc ce qui contraint la conception ou pourrait la faire échouer.

Contraintes

Qu'est-ce qui ne peut pas être ignoré ?

  • Réglementations
  • Auditabilité
  • Explicabilité
  • Approbation humaine
  • Confidentialité
  • Latence

Risques

Qu'est-ce qui pourrait mal tourner ?

  • Hallucination
  • Biais
  • Décisions incorrectes
  • Fuite de données
  • Responsabilité

C'est ici que la carte de problème devient particulièrement utile pour l'architecture IA. Un risque peut devenir un garde-fou. Une contrainte peut devenir une limite de conception. Une exigence de conformité peut devenir un point de contrôle. La carte commence à créer la matière première de l'architecture.

 

 

4. Donnez une place à l'incertitude sur le diagramme

C'est peut-être la partie la plus précieuse de l'exercice. Les diagrammes d'architecture ont tendance à avoir une propriété fâcheuse : tout semble certain.

Une boîte est une boîte. Une connexion est une connexion. Un composant est un composant.

Mais au début d'un projet d'IA, il y a des choses que nous ne savons tout simplement pas encore. Rendez donc l'incertitude explicite. Créez une branche Questions ouvertes.

Par exemple :

  • Qui possède la politique de crédit ?
  • Où vivent les seuils ?
  • Quelle source fait autorité ?
  • Qui répond à un litige ?
  • Quelle est la marge de révision ?

Cela change la conversation. Au lieu de faire semblant que l'architecture est prête, vous pouvez dire : Voici les questions auxquelles nous devons répondre avant que l'architecture soit prête.

Et parfois, ces questions révèlent que le projet n'est pas principalement un problème d'IA du tout. Peut-être que le vrai problème est une connaissance fragmentée. Peut-être que la propriété de la décision n'est pas claire. Peut-être qu'il n'y a pas de source de vérité fiable. Peut-être que le processus lui-même n'a jamais été correctement défini.

En d'autres termes, la carte de problème peut révéler que vous résolvez le mauvais problème. Et c'est une découverte très précieuse à faire avant de construire quoi que ce soit.

 

 

5. Laissez l'architecture émerger de la carte

Ce n'est que maintenant que vous devriez commencer à concevoir le système. La mind map devient utile au-delà du brainstorming parce que ses branches peuvent être tracées dans la conception.

Carte du problème Conséquence architecturale
DécisionsPérimètre de l'agent et critères de succès
DonnéesExigences de données et intégrations
PolitiquesSources de connaissances et récupération
ActeursPermissions et interaction humaine
SystèmesOutils et intégrations système
RisquesGarde-fous et portes humain-dans-la-boucle
ContraintesExigences non fonctionnelles
Questions ouvertesDécisions qui doivent être tranchées

 

La transformation n'est pas automatique. C'est une étape de raisonnement. Mais la carte vous donne quelque chose de précieux : la traçabilité. Chaque composant majeur de l'architecture devrait pouvoir s'expliquer par quelque chose découvert dans l'espace problème.

Si vous trouvez un composant d'architecture qui n'a aucune raison d'exister dans la carte de problème, demandez : Pourquoi est-ce ici ?

Et si la carte de problème contient une branche importante sans conséquence architecturale, demandez : Où est-ce adressé ?

Une discipline simple émerge : Rien d'inventé. Rien d'oublié.

 

 

Du problème à l'architecture

C'est ici que je trouve la relation entre les différents types de diagrammes particulièrement intéressante. Une mind map de problème ne remplace pas un diagramme d'architecture. Elle vient avant lui.

 

Pensez à la progression comme ceci :

Mind Map
Quel est le problème ?
↓
Workflow
Que doit-il se passer ?
↓
Séquence
Qui interagit avec qui, et quand ?
↓
Architecture
Que devrions-nous construire ?

 

Chaque représentation répond à une question différente. Ensemble, elles créent une chaîne de raisonnement continue de la définition du problème à la conception du système. La clé n'est pas de forcer un diagramme à tout faire. La clé est d'utiliser chaque diagramme pour la question à laquelle il est bon de répondre.

 

 

Quand une mind map ne sera pas utile

Tous les problèmes n'en ont pas besoin. Si :

  • le problème est déjà bien compris,
  • les limites sont convenues,
  • le vocabulaire est partagé,
  • les parties prenantes s'accordent sur ce qui doit être construit,

alors dessiner une mind map peut simplement vous ralentir. La carte serait juste de la procrastination avec une meilleure typographie.

Utilisez-la quand l'espace problème est incertain, transversal, politiquement ambigu, riche en connaissances, ou susceptible d'exposer des dépendances cachées.

Et ne la laissez pas devenir une liste de souhaits. Si chaque nœud devient une demande de fonctionnalité, vous avez quitté la définition du problème pour entrer dans la collecte d'exigences. Une mind map de problème est un outil de pensée, pas une représentation canonique de la réalité.

Deux architectes peuvent cartographier le même problème différemment. C'est très bien. La valeur réside dans la conversation structurée qu'elle crée.

 

 

La vraie valeur n'est pas l'image

Une bonne mind map de problème rend visibles des choses faciles à manquer quand tout le monde est impatient de commencer la conception :

  • quelles décisions comptent,
  • quelles informations comptent,
  • quelles connaissances sont requises,
  • qui est impliqué,
  • quels systèmes existent déjà,
  • ce qui peut mal tourner,
  • ce qui contraint la conception,
  • et ce que vous ne savez pas encore.

Ce dernier point compte.

Une architecture traditionnelle dit : « Voici le système. »

Une carte de problème peut aussi dire : « Voici ce que nous savons, ce que nous croyons, et ce qui reste non résolu. »

Cela fait de la carte plus qu'un exercice de brainstorming. Elle devient un moyen d'exposer l'incertitude avant que l'incertitude ne devienne du rework.

 

 

Pourquoi cela compte encore plus avec l'IA

Il y a un paradoxe dans l'architecture IA. Plus l'IA devient bonne pour produire des solutions, plus il devient facile de sauter la définition du problème. Demandez à un LLM de concevoir un agent de support et il vous donnera probablement quelque chose de plausible. Demandez-lui une architecture multi-agents et il en fournira volontiers une. Le résultat peut même être techniquement sophistiqué.

Mais la sophistication n'est pas la même chose que la pertinence. La compétence rare est de moins en moins : « Puis-je concevoir une architecture ? » Elle devient : « Est-ce que je sais quelle architecture devrait exister ? » C'est pourquoi l'espace problème mérite un modèle explicite.

 

 

Un modèle continu du problème au système

C'est aussi là qu'un outil de diagrammation peut devenir plus qu'un endroit pour dessiner des boîtes. Si le problème est représenté comme des données structurées, il n'a pas à mourir sur un tableau blanc. Le même modèle peut évoluer à mesure que votre compréhension évolue. La définition du problème peut mener au workflow. Le workflow peut mener à la séquence. La séquence peut mener à l'architecture. L'artefact n'est pas nécessairement jeté à chaque étape.

La pensée se transmet. C'est l'idée derrière FlowZap : Cartographiez le problème. Modélisez le comportement. Concevez le système. Dans cet ordre.

 

 

Dernière pensée

La meilleure architecture IA n'est pas celle avec les composants les plus intelligents. C'est celle qui résout le bon problème. Alors avant de dessiner le système, essayez de dessiner le problème. Vous découvrirez peut-être que vous avez besoin d'un agent. Vous découvrirez peut-être que vous avez besoin d'un workflow. Vous découvrirez peut-être que vous avez besoin de meilleures données ou d'une source de vérité plus claire. Ou vous découvrirez peut-être que vous ne devriez encore rien construire.

C'est exactement le genre de découverte qu'un architecte devrait faire avant l'apparition des boîtes.

 

 

Sources

Retour à tous les articles du blogue