En bref
- Le client n’a pas besoin de savoir comment ça marche. Il a besoin de savoir ce que ça coûte, combien de temps ça prend, quel est le risque et ce qui change pour lui.
- Montrez l’effet à l’écran, comme la page lente ou le paiement qui bloque, au lieu de le décrire.
- Une comparaison tirée de l’univers du client aide ; dites où elle s’arrête.
- Proposez deux ou trois options avec leur coût, leur délai et leur risque, et recommandez-en une.
- Ne montrez jamais de code que le client n’a pas demandé, ni aucun identifiant.
Pour expliquer des choix techniques à un client qui n’est pas technique, parlez de ce qui change pour lui, pas de la façon dont ça marche : ce que ça coûte, combien de temps ça prend, ce qui se passe si on ne le fait pas, et ce qui change pour son équipe. Montrez le problème à l’écran au lieu de le décrire, proposez deux ou trois options avec leurs compromis, et recommandez-en une. Un court enregistrement d’écran est un bon format pour ça, parce que le client voit de ses propres yeux la page lente ou le bouton cassé.
Ce guide s’adresse aux développeurs freelances et aux équipes d’agence qui ont besoin d’une décision du client sur un sujet qu’il ne peut pas évaluer seul.
Parlez résultats et compromis
Votre client se moque du framework, de la base de données ou de l’extension. Il s’intéresse à quatre choses :
- Le coût : combien maintenant, et combien chaque mois ensuite.
- Le délai : combien de temps, et si ça décale la mise en ligne.
- Le risque : ce qui se passe si on ne le fait pas.
- Le changement : ce qui est différent pour lui et son équipe ensuite.
Traduisez chaque point technique dans ces termes avant de l’expliquer :
| Ce que vous diriez à un collègue | Ce que le client a besoin d’entendre |
|---|---|
| « L’extension de réservation n’est plus maintenue. » | « Le système de réservation ne recevra plus de correctifs de sécurité. Il fonctionne aujourd’hui, mais chaque mois où on le garde, le risque augmente. » |
| « Il faudrait ajouter du cache. » | « Les pages se chargeront plus vite. Après une modification, le changement peut mettre quelques minutes à apparaître. » |
| « On passe sur un CMS headless. » | « Plus de liberté côté design, mais deux systèmes à maintenir au lieu d’un, et un coût mensuel plus élevé. » |
| « Il y a beaucoup de dette technique. » | « Des raccourcis pris auparavant rendent chaque nouvelle fonctionnalité plus lente et plus chère à développer. » |
Si une phrase a encore besoin d’un mot technique pour avoir du sens, expliquez ce mot une fois, en passant, et continuez.
Montrez, ne décrivez pas
« La page est lente sur mobile », c’est une opinion. Un enregistrement de la page qui met une éternité à afficher les photos produits dans une fenêtre de la taille d’un téléphone, c’est un fait que le client peut voir. La vidéo est le moyen le plus simple de montrer un problème technique à quelqu’un qui n’est pas devant votre écran :
- Le problème tel que le voit le client final : le bouton de paiement qui ne fait rien sur Safari, le formulaire qui efface ce qu’on a saisi.
- L’avant et l’après : l’ancienne page et la plus rapide, côte à côte.
- L’écran qu’il utilisera : l’interface d’administration après le changement, pour que « un nouvel éditeur » cesse d’être abstrait.
Entourez la partie importante pendant que vous parlez. Dessiner à l’écran pendant l’enregistrement le fait très bien ; voir comment dessiner sur l’écran de votre Mac pendant un enregistrement.
Utilisez les comparaisons avec prudence
Une bonne comparaison tirée de l’univers du client peut tout éclairer d’un coup. Quelques-unes qui fonctionnent souvent :
- La maintenance et les mises à jour, c’est comme l’entretien d’une voiture : si on le saute, elle roule encore, jusqu’au jour où elle ne roule plus.
- La dette technique, c’est comme une cuisine de restaurant qu’on ne nettoie pas entre deux services : chaque service est plus lent que le précédent.
- Les sauvegardes, c’est comme une assurance, sauf qu’il faut vérifier qu’elles fonctionnent avant d’en avoir besoin.
Une comparaison par décision, pas une par phrase. Et dites où elle s’arrête : « contrairement à une voiture, une faille de sécurité peut être exploitée par quelqu’un d’autre avant que rien ne paraisse anormal ». Une comparaison qui masque un coût ou un risque est pire que pas de comparaison du tout.
Proposez des options chiffrées
La plupart des décisions techniques ont plus d’une réponse. Présentez-en deux ou trois, y compris « ne rien faire » quand c’est une vraie option, et mettez-les côte à côte :
| Option | Délai | Coût récurrent | Risque |
|---|---|---|---|
| Garder l’existant | Rien pour l’instant | Aucun | Augmente chaque mois sans correctifs |
| La remplacer par une extension maintenue | Environ deux jours | Une licence annuelle | Faible ; les réservations sont transférées |
| Développer un formulaire de réservation sur mesure | Environ deux semaines | Notre temps de maintenance | Faible, mais plus de choses à suivre |
Exemple fictif : les délais et les coûts dépendent du projet.
Recommandez ensuite une option et dites pourquoi, en une phrase : « Nous la remplacerions par l’extension maintenue : deux jours de travail, et le risque disparaît. » Les clients décident plus vite quand vous avez fait le travail de réflexion et qu’ils n’ont plus qu’à donner leur accord. Côté budget, présenter un devis à un client en vidéo repose sur la même approche.
Une structure pour l’explication
Que vous enregistriez une vidéo ou que vous écriviez un e-mail, cet ordre fonctionne :
- La décision en une phrase. « Il faut qu’on décide quoi faire du système de réservation. »
- Pourquoi maintenant. Ce qui se passe si on attend, dans ses termes à lui.
- Montrez-le. Le problème à l’écran, trente secondes maximum.
- Les options, avec le délai, le coût et le risque.
- Votre recommandation et la raison.
- La demande, avec une date. « Pouvez-vous me dire d’ici vendredi quelle option vous préférez ? »
Choix technique : une extension qui n’est plus maintenue
D’un développeur freelance à une petite entreprise cliente · Environ 3 minutes
Bonjour Camille, j’ai besoin d’une décision de votre part sur le système de réservation. Rien n’est cassé aujourd’hui, mais l’extension qui le fait tourner n’est plus maintenue : elle ne recevra donc plus de correctifs de sécurité.
Voici la page de réservation telle que la voient vos clients. Il y a trois options : la laisser telle quelle, ce qui ne coûte rien maintenant mais devient plus risqué chaque mois ; la remplacer par une extension maintenue, environ deux jours de travail plus une licence annuelle ; ou développer notre propre formulaire, environ deux semaines. Je choisirais la deuxième : elle règle le risque et votre équipe ne verra pas la différence. Vous pouvez me dire d’ici vendredi ?
Envoyez-la avec la demande par écrit, pour que Camille puisse répondre depuis son téléphone sans relancer la vidéo :
Bonjour Camille, trois minutes sur le système de réservation. Rien n’est cassé, mais l’extension ne recevra plus de correctifs de sécurité. Je vous recommande de la remplacer (environ deux jours de travail). Vous pouvez me dire d’ici vendredi quelle option vous préférez ?
https://justrec.app/v/k3f9Qa
Ce qu’il ne faut pas montrer
Un enregistrement d’écran pour un client n’est pas une revue de code. Laissez de côté :
- Le code. Sauf si le client l’a demandé, le code signale « c’est compliqué », et rien d’autre.
- Les identifiants. Mots de passe, clés API, fichiers d’environnement, historique du terminal avec des jetons. Transmettez les accès via un gestionnaire de mots de passe, jamais dans une vidéo.
- Les journaux contenant des données clients. Les journaux d’erreurs contiennent souvent des noms, des e-mails et des détails de commandes.
- Les projets d’autres clients. La barre latérale de votre éditeur et vos onglets de navigateur peuvent les faire apparaître.
- Les discussions internes au sujet du client ou du problème.
Quand l’expliquer en direct
Certaines décisions techniques sont trop importantes pour une vidéo seule : une refonte, un changement de plateforme, tout ce qui modifie beaucoup le budget. Envoyez la vidéo en préparation, puis décidez lors d’un court appel. Nous traçons la limite entre les deux dans quand ne pas envoyer de vidéo à un client.
Et gardez ces explications pour plus tard. En fin de projet, la même approche donne une bonne livraison : la vidéo de livraison du site montre au client comment tout fonctionne sans une seule ligne de code. Le guide complet de la vidéo asynchrone dans la communication client réunit le tout, et notre page pour les freelances montre comment JustRec s’adapte à une activité en solo.
Questions fréquentes
Comment expliquer un choix technique à un client non technique ?
Commencez par ce qui change pour lui : le coût, le délai, le risque et le travail au quotidien. Montrez le problème à l’écran, proposez deux ou trois options avec leurs compromis, recommandez-en une, et demandez une décision avec une date.
Faut-il montrer du code à un client ?
Presque jamais. Pour un client non technique, le code dit que quelque chose est compliqué, pas pourquoi c’est important. Montrez plutôt la page, l’erreur ou l’écran d’administration qu’il utilisera.
Les comparaisons sont-elles une bonne idée pour expliquer un sujet technique ?
Oui, une à la fois et tirée de l’univers du client. Dites où la comparaison cesse de fonctionner, pour qu’elle ne masque ni un coût ni un risque.
Et si le client demande les détails techniques ?
Donnez-les, brièvement, après le résultat. Certains clients ont un technicien de leur côté qui les voudra ; proposez une courte note écrite pour cette personne.
Faut-il expliquer les choix techniques en vidéo ou en réunion ?
Une courte vidéo suffit pour la plupart des décisions, parce que le client voit le problème et peut revoir les options. Pour les choix importants ou coûteux, envoyez d’abord la vidéo et décidez lors d’un appel.
