6 règles pour poser une bonne question.

Aaaah les joies de l’entraide, chez Moocaccino on connaît bien. Que ça soit sur le discord ou bien en présentielle, on le sait, l’entraide, c’est cool. Que tu sois junior ou un vieux de la vieille qui codait sur cartes perforées en compagnie de tes potes dinosaures, tu as toujours quelque chose à apporter aux autres. Alors oui ça te prend du temps, mais quelle satisfaction d’avoir pu aider une consœur ou un confrère … Sauf que parfois, ta patience est mise à rude épreuve.

Et oui, parce que répondre à une question, ça demande pas mal d’investissement, tu dois comprendre le problème de ton interlocuteur, intégrer dans ta cervelle ses problématiques, le but visé et enfin trouver une solution satisfaisante, et ce, dans un temps raisonnable (parce que tu as tes propres problèmes à régler).

Bon jusque là, rien de bien anormal, c’est tout à fait logique et courant comme situation … Mais tu le vois venir, ce gros problème quand ton interlocuteur ne fait pas d’effort pour te faciliter la tâche. Je parle ici des gens qui te posent des questions imprécises.

C’est quoi une question imprécise ?

Ma définition de la question imprécise est assez simple:

Une question est imprécise si la personne à laquelle elle est posée doit perdre du temps à en comprendre le sens ou les enjeux.

Dit comme ça, ça paraît super vague, et très dépendant de la capacité de compréhension de ton interlocuteur, cependant, il existe des erreurs que répètent sans cesse les gens qui posent des questions imprécises. Alors oui, on pourrait les blâmer, mais je suis plutôt d’avis que poser une question est une chose qui s’apprend. Voici donc une liste, non exhaustive, de règles à appliquer pour poser une bonne question.

I ) LE CONTEXTE TU DÉCRIRAS

Cette règle est indispensable, on ne compte plus le nombre de questions restées sans réponses ou qui ont pris une éternité par manque de contexte. Quand on code, le contexte technique dans lequel on évolue va dans 99% des cas conditionner la réponse. Le plus simple étant de faire un bref descriptif technique du projet.

Par exemple, évite de dire:

« Mon formulaire ne fonctionne pas »


Mais plutôt:

« Bonjour, mon site tourne sous l’environnement technique suivant:
– Framework: Prestashop v1.7.6.3
– Serveur: VPS loué chez OVH
– OS: Ubuntu 18.04
– SGBDR: MySQL

Mon formulaire ne fonctionne pas, pouvez-vous m’aider ? »

Bon cette liste n’est pas exhaustive, mais elle a au moins le mérite de donner un contexte à la question. Tu peux donner d’avantage de détails, comme le moteur de template utilisé etc … Bref, sois le plus précis possible ! Bien entendu, la question en elle-même n’est pas bien posée mais on y reviendra plus tard.

II ) LE BUT, TU DÉCRIRAS

Ça peut paraître un peu redondant avec le premier conseil, mais en vérité, on est plus proche de quelque chose de complémentaire. En effet, nous avons eu jusqu’ici une brève description de l’environnement technique mais nous ne savons rien de précis concernant ce que l’on souhaite vraiment faire. « Mon formulaire ne fonctionne pas » n’est pas une question, mais un fait.

Bien sur il paraît évident que l’aide devra s’orienter sur comment faire fonctionner le formulaire. Mais même si on fait l’effort de deviner, on ne sait pas de quel formulaire il s’agit, ni même ce que formulaire est supposé faire. On perd donc du temps à comprendre la question et ça c’est mal !

Donc au lieu de dire:

« Mon formulaire ne fonctionne pas, pouvez-vous m’aider ? »

Dites-plutôt:

« Bonjour, dans le cadre de mon projet de site web e-commerce, je cherche à créer un formulaire de prise de contact. Celui-ci doit donner la possibilité à un client de contacter le support ainsi que le SAV. L’environnement technique est le suivant … (notre environnement technique décrit plus haut) … Ce formulaire ne fonctionne pas, pouvez-vous m’aider ? »

La question est encore loin d’être parfaite, mais au moins, on connaît maintenant le but final visé !

III ) PRÉCIS TU SERAS

Une grosse erreur consiste à dire « ça marche pas » …. Et à attendre la réponse. Le code n’a pas de jambes … pas étonnant qu’il ne marche pas ! À la place dis-nous plutôt ce qui ne fonctionne pas de façon précise. Pour notre formulaire, ici, on n’a aucune idée de ce qui ne fonctionne pas.

– Est-ce l’envoi de mail qui déconne ?
– Le formulaire bugge-t’il lors du traitement des données POST ?
– Ou peut être cela bugge t-il au niveau de l’insertion des données en BDD ?

Bref, « ça marche pas » ne veut rien dire. Précise plutôt ce qui ne fonctionne pas exactement selon toi. Quel est le comportement attendu et quel est le comportement obtenu à la place.

Ainsi, on ne dit pas:

« Mon formulaire ne marche pas ».

Mais plutôt:

« Lorsque je valide mon formulaire, je m’attends à ce que le service concerné reçoive un email, or le mail n’arrive jamais, ni dans la boîte de la réception, ni dans les spams, ni ailleurs. »

… Il y a du mieux, mais on peut encore mieux faire !

IV) LES « STEPS TO REPRODUCE », TU FOURNIRAS

C’est très bien de demander de l’aide, c’est très bien d’y mettre les formes, maintenant il faut expliquer comment on reproduit le bug étape par étape ! En ce qui concerne notre formulaire c’est extrêmement simple, il suffit apparemment de soumettre ledit formulaire, mais nous allons admettre ici que le bug se produit uniquement sur le serveur de production.

Version imprécise:

« Lorsque je soumets mon formulaire … « 

Version précise:

« Sur mon localhost tout fonctionne, mais sur le serveur de production, lorsque je soumets mon formulaire cela ne fonctionne pas car … etc etc … »

V) TON CODE TU PUBLIERAS

Parce que oui, jusqu’ici on n’a pas parlé du plus important à savoir rendre le code facilement accessible aux personnes qui vont nous aider. Pour ce faire il existe plein d’outils comme:

  • Github: Bah oui, tu bosses avec un outil de suivi de version non ? Si le dépôt est public, tu peux donner le lien aux personnes concernées.
    N’oublie pas de bien remplir le fichier README.md, histoire que n’importe qui puisse installer le projet facilement.
  • Gist: Si le projet n’est pas hébergé sur un dépôt public, tu peux au moins isoler la partie du code qui nous intéresse et la publier sur un gist. N’oublie pas de commenter le code.
  • Codepen: Bon admettons que Gist et Git ne soient pas ta tasse de thé, tu peux toujours utiliser codepen qui reste un excellent outil pour montrer son travail, même si techniquement, codepen est d’avantage là pour montrer un travail fini.
  • … Et il en existe plein d’autres.

Il est donc parfaitement inutile à l’avenir de poster le code sur les plateformes de type discord, tchats, slack etc … Pourquoi ? Mais parce que:

  • C’est illisible, la plupart du temps, il n’y a pas de coloration syntaxique.
  • Il n’y a aucun outil, pas d’auto-complétion, ni debugger etc …
  • Le code et la discussion autour du code sont mélangés, et c’est bordélique.

Pour résumer, utilise des outils adaptés pour partager ton code. On y est presque, plus qu’un dernier conseil et on devrait avoir une bonne question.

VI) TON ÉCRITURE TU SOIGNERAS

Alors, vu que l’on est sur internet, on ne va pas parler de calligraphie mais bien des sujets qui fâchent à savoir, l’orthographe, la grammaire, la ponctuation et la conjugaison. Et comme j’entends déjà gueuler dans le fond, je préfère préciser de suite qu’on n’attend pas de toi une prose digne de Molière mais juste un truc compréhensible dès la première lecture.

Henry, voulez-vous bien me passer la plume d’oie je vous prie ?

Comme je n’ai pas envie de me transformer en professeur de français (je n’en ai ni l’envie ni les compétences), je préfère te conseiller de faire vérifier ton texte par un(e) ami(e) avant de l’envoyer. Tu n’as pas d’ami sous la main ? Ou pire, tu préfères ne pas leur demander de peur qu’ils ne rajoutent des fautes supplémentaires ? Et bien dans ce cas les correcteurs en ligne sont tes amis !

Encore une fois, le but n’est pas de t’ennuyer mais bien de donner envie aux autres de te répondre. Je pense avoir pour ma part, une certaine tolérance à la faute d’orthographe (tout le monde en fait, même lui ) mais il faut bien avouer que passé un certain cap, c’est démotivant.

Pour la grammaire et la conjugaison, parfois il suffit seulement de relire son texte à voix haute pour s’apercevoir qu’il y a un couac quelque part. Si tu as peur de passer pour un(e) dingue au milieu de l’open space, parle à ton canard en plastique, chez les devs, c’est considéré comme normal.

Tu me passes le savon ducky ?

Pour la ponctuation c’est la même chose, relis à voix haute et ne reprends ta respiration que lorsque tu croises un point, une virgule, ou un nouveau paragraphe. Si tu manques d’air, c’est que ton texte est trop compact.

Conclusion

Et voilà, armé de cette petite liste, tu peux maintenant écrire la question parfaite, nul doute que tes interlocuteurs te remercient d’avance. N’hésite pas à partager cette liste à tes voisin(e)s ! Quand à moi je te dis à bientôt, devant un petit café !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *