Pour expliquer un projet technique à un public non technique, commencez par la conséquence qu’il doit comprendre, puis montrez assez du mécanisme pour rendre les éléments de preuve et les compromis intelligibles. Remplacer les mots techniques par des mots plus courts n’aide que si le raisonnement devient réellement plus facile à suivre.
Vos collègues connaissent peut-être mieux que vous le client, le processus opérationnel ou le budget. Ce qui leur manque parfois, c’est le contexte spécialisé qui se cache derrière un schéma d’architecture. Construisez ce contexte avec soin, sans supprimer les incertitudes dont ils ont besoin pour évaluer la proposition. Pour préparer une première trame de diapositives modifiables, vous pouvez ensuite transformer ce brief en présentation avec Presenti, en conservant les limites des éléments disponibles.
Commencer par la question à laquelle le public doit répondre
Notez les rôles présents et l’action que vous attendez d’eux. Un responsable du support peut devoir expliquer aux clients un changement de comportement. Un chef de produit peut devoir choisir le périmètre d’un pilote. Un collègue de la finance peut devoir comprendre l’engagement de ressources. Ces questions ne demandent pas le même niveau de détail qu’une revue de code.
Dans l’exemple développé ici, une équipe d’ingénierie veut obtenir l’autorisation de tester une nouvelle manière de générer des rapports. Le public réunit les équipes produit, opérations et support. Il doit comprendre ce que les utilisateurs verront, ce qui pourrait mal se passer et quelles preuves seront nécessaires avant un déploiement plus large.
Le guide du Communication Lab du MIT EECS pour les diapositives recommande d’adapter l’explication aux connaissances du public, d’introduire les chiffres inconnus et de donner à chaque diapositive un message clair. Appliquez ce principe en décidant quelle partie du mécanisme le public doit connaître avant de montrer l’architecture complète.
Avant et après : expliquer une proposition de rapports avec file d’attente
Cet exemple de communication a été rédigé pour ce guide. Le système proposé et les données d’exercice ci-dessous illustrent une réécriture de diapositive ; ils ne correspondent ni aux résultats d’un client ni à un test réalisé sur un produit en ligne.
La première diapositive s’intitule « Orchestration asynchrone avec files durables et workers idempotents ». Son schéma contient une passerelle API, une file d’attente, des processus de traitement, une base de données, des flèches de nouvelle tentative et des composants de supervision. Un ingénieur reconnaîtra peut-être ce modèle. Les autres collègues doivent tout de même comprendre ce qui change pour une personne qui demande un rapport.
Réécrivez le titre ainsi : « L’utilisateur peut quitter la page pendant la préparation du rapport. » En dessous, montrez la séquence proposée :
- L’utilisateur demande un rapport.
- L’application accuse réception de la demande et enregistre une tâche en attente.
- Un processus en arrière-plan prépare le rapport.
- L’application affiche le résultat terminé ou un statut d’échec explicite.
Ajoutez cette distinction essentielle à côté du schéma : Demande acceptée ne signifie pas rapport prêt. Un accusé de réception rapide peut modifier l’attente ressentie, mais il ne prouve pas à lui seul que le calcul se termine plus vite.
Les recommandations de Microsoft sur le nivellement de charge par file d’attente expliquent comment une file sépare l’arrivée des tâches de leur traitement. Elles indiquent aussi qu’une file s’allonge lorsque les tâches arrivent plus vite qu’elles ne peuvent être traitées. Pour cette présentation, cela devient une question simple : « Que verront les utilisateurs si l’arriéré augmente ? »
Conserver les termes techniques nécessaires à la décision
Certains termes méritent une définition ; d’autres peuvent rester dans l’annexe destinée aux ingénieurs. Expliquez une fois le terme nécessaire dans son contexte, puis utilisez toujours la même formulation.
| Terme technique | Explication pour le public | Question à laquelle il aide à répondre |
|---|---|---|
| File d’attente | Endroit où les demandes de rapport en attente patientent avant leur traitement. | Que se passe-t-il lorsque beaucoup de personnes demandent un rapport en même temps ? |
| Worker | Processus en arrière-plan qui crée le rapport. | Qu’est-ce qui continue le travail après le départ de l’utilisateur ? |
| Nouvelle tentative | Nouvel essai après l’échec ou l’interruption d’une tâche. | Comment une demande en échec est-elle reprise, et quand faut-il intervenir ? |
| Traitement idempotent | Traitement répété d’une même tâche sans produire un résultat en double involontaire. | Qu’est-ce qui empêche une nouvelle tentative de créer des enregistrements ou des actions en double ? |
Le tableau n’établit pas que le système proposé gère déjà correctement ces situations. Il indique ce que l’équipe d’ingénierie doit expliquer ou tester. Gardez le traitement réel des échecs, les choix d’implémentation et les résultats des tests dans les documents de référence.
Une analogie peut servir de point d’entrée : une file d’attente ressemble à une file de tickets qui attendent d’être traités. Précisez où l’analogie cesse d’être utile. Dans un système réel, plusieurs workers et plusieurs tentatives peuvent modifier l’ordre de traitement ; une image simple du premier arrivé, premier servi pourrait donc suggérer un comportement que la conception ne garantit pas.
Rendre les preuves compréhensibles sans les exagérer
Utilisez ce petit jeu de données comme exercice d’écriture de diapositive : sur 100 demandes de rapport, 90 se terminent en moins de 60 secondes et 10 prennent plus de temps. Supposons que la proposition fixe un objectif de 95 % en moins de 60 secondes. Ces données sont illustratives ; elles ne sont pas les résultats mesurés d’un système examiné pour cet article.
| Ce que dit l’exemple | Ce que vous pouvez conclure |
|---|---|
| 90 demandes sur 100 se terminent en moins de 60 secondes. | La proportion dans cet intervalle est de 90 %. |
| L’objectif illustratif est de 95 % en moins de 60 secondes. | L’échantillon est inférieur à l’objectif ; un accusé de réception rapide ne résoudrait pas cet écart. |
| Aucune comparaison avec le système actuel n’est fournie. | L’exemple n’établit pas une amélioration des performances. |
| Aucune ventilation des dix demandes plus lentes n’est fournie. | La cause du délai reste une question, pas un constat. |
Une diapositive faible affirme : « La nouvelle architecture rend les rapports rapides. » Un titre plus utile serait : « L’échantillon d’exercice n’atteint pas l’objectif de délai proposé. » Affichez le dénominateur et le seuil à côté du visuel, puis indiquez quelles preuves supplémentaires pourraient changer la décision.
Pour une proposition réelle, précisez quand le chronomètre démarre et s’arrête, la charge de travail, le nombre de demandes et la manière dont les échecs sont comptés. Séparez les résultats observés, les prévisions et les valeurs cibles. Si la diapositive compare le système actuel au système proposé, utilisez des conditions comparables ou expliquez les différences. Le guide de visualisation des données développe davantage ce chemin entre preuve et action.
Un briefing en six diapositives qui conserve la question d’ingénierie
Voici une trame copiable pour l’exemple des rapports. Remplacez les détails illustratifs par des éléments du projet examinés avant de l’utiliser au travail.
Diapositive 1 : expliquer l’expérience actuelle
Titre : « La création du rapport oblige l’utilisateur à rester sur la page. »
Explication orale : « Aujourd’hui, l’utilisateur doit attendre ici jusqu’à la préparation du rapport. Nous évaluons un parcours qui accuse réception de la demande et rend le résultat disponible ensuite. » Montrez les étapes actuelles et n’ajoutez pas de taux d’échec que vous n’avez pas mesuré.
Diapositive 2 : montrer ce qui changerait
Titre : « Le parcours proposé sépare la demande du rapport de sa réception. »
Explication orale : « L’application enregistre la demande, un processus en arrière-plan crée le rapport et l’utilisateur voit son statut. L’accusé de réception et l’achèvement sont deux événements distincts. » Utilisez le schéma en quatre étapes plutôt que la carte complète du déploiement.
Diapositive 3 : expliquer ce qui est connu
Titre des données d’exercice : « 90 % se terminent en moins de 60 secondes, sous l’objectif proposé de 95 %. »
Explication orale : « Cet échantillon illustratif comporte 100 demandes. Dix dépassent le seuil. Nous avons besoin de mesures représentatives et d’une référence du système actuel avant de parler d’amélioration. » Dans un briefing réel, remplacez cet exercice par les preuves disponibles et leurs limites.
Diapositive 4 : rendre visible la nouvelle responsabilité
Titre : « Le nouveau parcours exige un statut et une reprise clairement définis. »
Explication orale : « Les utilisateurs doivent savoir si un rapport est en attente, terminé ou en échec. Le support doit pouvoir distinguer une tâche lente d’une tâche qui exige une intervention. La conception doit aussi gérer les nouvelles tentatives sans créer de doublons involontaires. » Renvoyez aux questions de conception et de test précises dans l’annexe.
Diapositive 5 : proposer une prochaine étape limitée
Titre : « Un pilote limité peut tester l’attente et la reprise après incident. »
Explication orale : « Convenons des participants, des conditions d’entrée, des mesures, des critères d’arrêt et de la personne responsable avant de commencer. Mesurons l’achèvement et les échecs, pas seulement l’accusé de réception. » Laissez les valeurs vides jusqu’à leur validation par les responsables.
Diapositive 6 : demander la décision que vous êtes prêt à accompagner
Titre : « Décider de lancer le pilote et de désigner la personne responsable de la revue. »
Explication orale : « Nous demandons un pilote au périmètre défini, suivi d’une revue des preuves convenues avant tout déploiement plus large. » Si un travail de conception non résolu empêche même cette étape, demandez l’action plus limitée qui permettra de le résoudre.
Garder une annexe capable de répondre à la question suivante
Le parcours simplifié doit mener aux détails de référence, pas les faire disparaître. Donnez à l’annexe des rubriques stables : architecture et dépendances ; définitions des mesures ; conditions de test ; gestion des échecs et des nouvelles tentatives ; alternatives étudiées ; responsabilité du déploiement ou du retour arrière. Depuis la diapositive principale, renvoyez à la page concernée.
Préparez-vous aux questions qui révèlent la distinction centrale. Si quelqu’un demande : « Les rapports seront-ils désormais instantanés ? », répondez en deux parties : la proposition modifie l’accusé de réception de la demande, tandis que l’achèvement du rapport dépend toujours du traitement et de la charge. Si quelqu’un demande : « Que se passe-t-il quand l’arriéré augmente ? », montrez le statut et le plan de reprise — ou dites clairement ce que l’équipe doit encore concevoir.
Testez l’explication avec une personne appartenant au public visé. Demandez-lui de décrire ce qui change pour l’utilisateur et la décision que vous sollicitez. Si elle ne retient que « un système plus rapide », la distinction entre accusé de réception et achèvement doit être rendue plus claire.
Préparer le brief avant de demander une première trame
Le brief d’explication technique et sa trame en six diapositives sont disponibles comme ressource texte copiable, avec les données illustratives et les distinctions à préserver.
Rassemblez le public, la conséquence pour l’utilisateur, le mécanisme résumé, les définitions nécessaires, les preuves examinées, les incertitudes et la décision demandée. Vous pouvez utiliser ce texte dans Presenti AI PPT Maker pour proposer un plan et une première trame. Faites relire les raccourcis par le responsable technique : une phrase plus fluide peut tout de même supprimer une condition importante.
Explique [projet] à [public et rôles]. Ils doivent comprendre ou décider : [tâche]. Utilise uniquement le mécanisme et les preuves fournis. Organise six diapositives autour de la conséquence, du mécanisme, des preuves, du compromis, de la prochaine étape et de la décision. Définis les termes inconnus nécessaires à la décision. Conserve les unités, les dénominateurs, les incertitudes et les limites. Signale les preuves manquantes au lieu de les inventer. Garde les détails d’implémentation dans une annexe référencée.
Le meilleur signe que l’explication fonctionne est une conversation plus précise : quelle condition reste irrésolue, quel compromis est acceptable et quelle preuve faut-il obtenir ensuite ? Ces questions donnent à l’équipe technique et à ses collègues une manière utile d’avancer.
