L'entretien de découverte de processus en 30 minutes : comment capturer un processus avant de le cartographier

La promesse de la cartographie de processus native IA est simple : vous chargez un document décrivant un processus, et vous obtenez un BPMN propre en deux minutes. La promesse tient, mais elle suppose implicitement que ce document existe déjà. Pour la plupart des PME et la plupart des consultants qui prennent un nouveau client, ce n'est pas le cas. Le mode opératoire n'a pas été mis à jour depuis 2019, les notes d'atelier sont éparpillées sur trois pages Notion, et la réalité actuelle du processus vit dans la tête des deux personnes qui le font tourner tous les jours. Avant l'upload, il y a une étape qui reçoit très peu d'attention : capturer cette connaissance dans un document unique, fidèle, prêt pour l'IA. La bonne nouvelle, c'est que cette étape prend 30 minutes, pas 30 heures.

Le facteur qui détermine le plus la qualité d'un BPMN généré par IA, ce n'est ni le modèle, ni le prompt engineering, ni le post-traitement. C'est l'input. Un transcript brut de 5 000 mots où un opérateur décrit comment il fait vraiment son travail produit, à la première passe, un diagramme plus précis qu'une SOP de 50 pages négociée politiquement jusqu'au consensus. Ce n'est pas un défaut des outils IA. C'est une caractéristique : l'IA est un traducteur fidèle de la prose vers la structure, et la traduction fidèle d'un mensonge poli produit un mensonge poli.

L'erreur la plus courante en entretien de découverte est d'interviewer le manager. Le manager décrit la politique : comment le processus est censé tourner, à quoi ressemblent les passations officielles, ce que disent les SLA. L'opérateur décrit la réalité : quelles étapes tout le monde saute parce que le système est lent, quelles approbations sont tamponnées d'office parce que la règle est inapplicable, et où le processus se ramifie selon qui est de service. Le diagramme issu d'un entretien manager est celui qui devrait exister. Le diagramme issu d'un entretien opérateur est celui qui existe vraiment.

Pour un processus typique de 20 tâches, l'opérateur c'est le chargé d'opérations, le conseiller client, ou l'analyste qui se trouve au milieu du flux de travail. Ce n'est pas la personne la plus senior impliquée, et c'est très rarement la personne qui a conçu le processus à l'origine. Cherchez la personne qui formerait le prochain nouveau venu, parce que cette personne est l'autorité pratique sur la façon dont le travail circule réellement.

Que faire quand le processus traverse plusieurs rôles

Beaucoup de processus réels traversent trois ou quatre rôles. Résistez à la tentation de tous les rassembler dans une seule réunion en table ronde : ce format produit un transcript dominé par la personne la plus senior ou la plus bavarde, les vrais opérateurs parlant en dernier et le moins. Faites plutôt des entretiens séparés de 20 minutes avec chaque opérateur, puis concaténez les transcripts avant l'upload. Le classifieur multi-source de l'IA fera émerger les contradictions entre les comptes rendus sous forme de questions de clarification, et c'est précisément le moment où apparaissent les insights les plus précieux : les contradictions marquent presque toujours les parties non documentées du processus.

Un entretien de découverte productif se déroule en quatre phases, dans cet ordre. L'ordre compte parce que chaque phase prépare l'IA pour une étape différente de son pipeline : déclencheur et issue ancrent les événements de début et de fin, le walkthrough produit la liste des tâches as-is, les exceptions alimentent la logique des gateways, et la wishlist est rangée comme une intention de cible séparée plutôt que mélangée au diagramme courant.

1. Phase 1, Déclencheur et issue (5 minutes). Quel événement déclenche ce processus ? Quel est l'état final visible du point de vue du client ? Capturez les deux clairement : l'IA s'en sert comme événement de début et événement de fin du BPMN. Un processus avec un déclencheur flou ('quand l'équipe se sent prête') et une issue floue ('le client est content') produit un diagramme aux frontières faibles qui dérive vers les processus voisins.
2. Phase 2, Walkthrough as-is (15 minutes). Demandez à l'interviewé de raconter un cas récent précis, de bout en bout, dans l'ordre où ça s'est passé. Utilisez un cas réel des deux dernières semaines, pas un cas typique abstrait. Format pensée à voix haute : 'la commande est arrivée dans ma boîte mail à 9h14, ensuite j'ai vérifié le compte client dans le CRM, ensuite j'ai vu que l'adresse était une boîte postale donc j'ai transféré à Jean au shipping...'. N'interrompez pas pour des clarifications pendant le walkthrough. Notez vos questions et posez-les après le récit. Interrompre fragmente la narration ; l'IA extrait mieux la séquence à partir d'un récit continu.
3. Phase 3, Exceptions et KPI (8 minutes). Qu'est-ce qui ne va pas dans 1 cas sur 10 ? Qu'est-ce qui ne va pas dans 1 cas sur 100 ? Quel est le délai habituel de bout en bout ? Combien de cas par semaine, par mois ? Combien coûte chaque étape, à peu près, en temps et en outils ? Vous alimentez ici la logique des gateways et les champs KPI. Des nombres approximatifs valent infiniment mieux que pas de nombres : une durée de '15 minutes' vaut mieux qu'une durée de 'un moment', et l'IA ne peut pas estimer un coût à partir de 'un moment'.
4. Phase 4, Parking lot wishlist (2 minutes). Que changeriez-vous si vous aviez carte blanche ? Quelle est l'étape la plus pénible ? Capturez ça fidèlement mais à part. L'IA traitera cela comme une intention d'état cible plutôt qu'un fait d'état actuel, ce qui est exactement ce que vous voulez.

Toute question productive en entretien de découverte tombe dans l'une de ces cinq catégories : acteurs, séquence, décisions, exceptions, KPI. Chaque catégorie cible une partie spécifique du BPMN que l'IA doit produire. Les questions ci-dessous sont formulées de manière ouverte, parce que les formulations ouvertes produisent des réponses narratives que l'IA extrait proprement, alors que les formulations fermées produisent des réponses oui/non qui dépouillent le contexte.

1. Acteurs : qui fait chaque étape

• Qui d'autre est impliqué dans ce processus à part vous ?
• Quand vous finissez votre partie, qui est la personne suivante à toucher ce travail ?
• Y a-t-il des étapes où la même personne joue un rôle différent selon le cas ? Par exemple, commercial dans certains, account manager dans d'autres ?

2. Séquence : ce qui se passe après quoi

• Racontez-moi un cas précis des deux dernières semaines, dans l'ordre où ça s'est passé. Ne résumez pas : dites-moi ce qui est venu en premier, en deuxième, en troisième.
• Quand vous recevez [événement déclencheur], quelle est la toute première chose que vous faites, avant tout le reste ?
• Y a-t-il parfois une étape qui se passe dans le désordre, du genre plus tard dans le processus vous devez revenir vers un système ou un rôle antérieur ?

3. Décisions : branches et conditions

• Y a-t-il des moments où vous devez choisir entre deux chemins ? Quel est le critère ?
• Y a-t-il des cas où vous sautez complètement une étape ? Qu'est-ce qui déclenche ce saut ?
• Y a-t-il des approbations qui peuvent être auto-servies versus des approbations qui doivent être escaladées ? Où est la frontière ?

4. Exceptions : ce qui casse, à quelle fréquence, et alors

• Quand est-ce que ce processus ne suit pas le plan ? Quel est le casseur le plus courant ?
• Qu'est-ce qui se passe environ 1 fois sur 10 et qui surprendrait quelqu'un d'extérieur ?
• Vous est-il déjà arrivé de devoir refaire une étape à cause d'une erreur en amont ? Racontez-moi ce qui déclenche ce travail à refaire.

5. KPI : durée, fréquence, coût

• Combien de temps prend le processus complet, de bout en bout, sur un cas normal, à peu près ?
• Combien en traitez-vous par semaine ou par mois ?
• Parmi les étapes que vous avez décrites, laquelle prend le plus de temps en travail actif ? Laquelle coûte le plus en outils ou en frais externes ?

Ces cinq erreurs expliquent presque tous les premiers BPMN faibles qu'on voit passer en support. Chacune est invisible dans le document d'entrée mais évidente dans le diagramme de sortie, raison pour laquelle elles tombent du côté préparation humaine plutôt que côté modèle.

1. Mélanger as-is et to-be dans le même transcript. L'interviewé décrit le processus actuel dans une phrase et une amélioration future espérée dans la suivante ('actuellement on route à la main, mais on veut ajouter un check de crédit automatique'). L'IA traitera les deux comme un fait d'état actuel sauf si la détection multi-intent l'attrape, et même dans ce cas le résultat est deux demi-diagrammes brouillés. Solution : quand l'interviewé glisse en mode wishlist, marquez-le explicitement dans le transcript ou gardez-le pour la phase 4.
2. Empiler plusieurs processus dans un seul entretien. Onboarding, renouvellement et résiliation sont trois processus distincts avec trois déclencheurs distincts. Un entretien qui dérive entre les trois produit un transcript que l'IA va soit mal découper, soit fusionner de manière incohérente. Solution : un processus par entretien, point.
3. Concevoir l'état cible pendant la découverte. La découverte est une activité de documentation, pas une activité de design. Au moment où la conversation devient 'et là on devrait ajouter une approbation', vous avez arrêté de capturer la réalité et vous avez commencé à l'inventer. Les deux sont utiles, mais ils appartiennent à des entretiens différents. Solution : parquez les idées d'amélioration explicitement en phase 4, et faites un entretien d'état cible séparé plus tard.
4. Enregistrer la politique au lieu de la réalité. L'interviewé décrit ce qui est censé arriver plutôt que ce qui arrive vraiment. C'est particulièrement courant quand un manager est dans la pièce. Solution : demandez 'racontez-moi le cas le plus récent' plutôt que 'comment ça marche en général', parce que les cas réels sont concrets et les politiques sont abstraites.
5. Trop nettoyer le transcript avant l'upload. Certains utilisateurs se sentent obligés de réécrire le transcript en SOP propre avant de l'uploader, en supposant qu'un input poli produit un output poli. C'est l'inverse : l'IA extrait mieux la structure de processus à partir d'une prose brute légèrement désordonnée que d'un résumé assaini, parce que le résumé perd les nuances, les cas limites et les décisions tacites que l'IA utilise pour alimenter les branches de gateway et les estimations KPI. Solution : uploadez le transcript exactement comme il sort du service de transcription. Avec les fautes de frappe et les euh.

La sortie d'un entretien de découverte de 30 minutes est exactement l'entrée que vous voulez pour une cartographie de processus par IA. Concrètement : un transcript de 3 000 à 6 000 mots, dans la voix de l'interviewé, organisé dans l'ordre où il a parcouru le processus, avec les chiffres KPI de la phase 3 attachés et les éléments de wishlist gardés dans une section séparée. Uploadez-le directement, sans réécriture.

Si vous avez plusieurs sources, déposez-les toutes en même temps : le transcript de découverte, plus toute SOP partielle existante, plus des captures d'écran des systèmes impliqués, plus deux ou trois emails représentatifs. Le flux d'upload est conçu pour ingérer plusieurs documents dans une même session et les traiter comme une source unifiée. L'IA fera émerger les contradictions entre eux sous forme de questions de clarification, et c'est précisément à ce moment que vos insights les plus précieux apparaissent : les contradictions marquent en général les parties du processus que personne n'a documentées.

Quel format fonctionne le mieux

• Texte brut ou markdown gagne sur la fiabilité. La sortie du service de transcription, collée telle quelle dans un .txt ou un .md, parse proprement et préserve la structure de la prose.
• Documents Word (.docx) marchent aussi bien pour l'IA mais ajoutent une couche de formatage qui cache parfois du contenu (notes de bas de page, fils de commentaires). Si vous recevez un Word que vous n'avez pas écrit, collez le texte dans un .txt simple et uploadez ça.
• PDF sont OK pour les SOP et les documents de politique, surtout quand la mise en page compte (tableaux, schémas). Ils ne sont pas idéaux pour les transcripts, où le formatage n'apporte rien et interfère parfois avec le parsing.
• Plusieurs sources courtes valent mieux qu'une longue source polie. Un transcript brut de 3 000 mots plus une SOP de 1 500 mots plus trois captures d'écran est un upload plus fort qu'un seul document poli de 8 000 mots, parce que les contradictions entre les sources font émerger des insights qu'un document poli aplanit.