La hotline de la programmation

Vous avez un problème avec votre IDE, un message d'erreur inconnu. Vous avez essayé 30 000 modifications sur votre code, passé la journée à vous creuser la tête, et peut-être même que vous avez cherché sur un moteur de recherche…

En désespoir de cause, vous allez poster sur un forum de programmation. Et là, mauvaise surprise : les « recherche », « Google is your friend », et autres « RTFM » fusent.

Ces réponses paraissent injustifiées, voire carrément méchantes : le membre a souvent cherché, pourtant il se fait traiter comme un enfant trop gâté.

Introduction alternative

Il y a longtemps, j'ai lu un article qui s'appelait « comment bien poser une question sur Internet », en anglais. Il était très intéressant, et j'ai pensé qu'une adaptation pourrait être bénéfique. Simplement, je vais ici développer le sujet du point de vue d'un questionneur, et pas de celui d'un contributeur comme le faisait l'article original. En conséquence, on s'intéresse plus ici au « comment éviter de se voir répondre RTFM » que de la psychologie des accros aux forums qui explique pourquoi on voit si souvent des réponses désagréables.

Nous partons d'une constatation complètement évidente : si quelqu'un pose une question, mais qu'il a déjà presque trouvé la réponse, et qu'il ne lui manque plus qu'un petit coup de pouce pour y arriver, lui répondre sera beaucoup plus facile que s'il n'a aucune idée de ce qui se passe.

À partir de là, en découle une « loi » qui devrait donc sembler complètement évidente également : chercher toute la journée, c'est bien, mais encore faut-il le montrer. Autrement dit, lorsque quelqu'un pose une question sur un forum, il est dans son intérêt d'expliquer tout ce qu'il a essayé de faire pour résoudre le problème, avant de demander : suis-je sur la bonne voie ?, plutôt que de simplement poster ça plante : pourquoi ?.

Le deuxième type de message, même s'il respecte toutes les règles habituelles de politesse, mise en forme (coloration du code), et utilisation du bon forum/de la bonne catégorie, aura bien moins de réponses, et des réponses plus sèches. C'est inévitable.

Expliquer ce qui se passe

Votre post doit donc être un genre de feuille de route de vos recherches, qui se conclut par une question : malgré tout ce que j'ai pu tenter, je suis toujours bloqué ici, par où continuer ?

Une bonne méthode pour rédiger un topic est donc de suivre l'ordre chronologique des événements. Par exemple, avant de rencontrer le problème on était en train de faire quelque chose. Tout à coup, un élément perturbateur¹ survient : un message d'erreur, un comportement inattendu. On le constate. C'est la première chose à écrire dans un topic : je voulais faire ceci cela, mais, au moment d'accomplir telle action, le message d'erreur suivant survient.

Il est vital de bien expliquer le problème et de poster le message d'erreur, ou, a défaut, de décrire précisément ce qui se passe. « Mon programme plante », « Mon code ne compile pas », ou, pire que tout, « ça marche pas » sont à bannir absolument et au plus vite. « Je vois un chameau à l'écran alors que ça devrait être un éleveur de grenouilles », « mon programme se ferme brusquement avec ce message d'erreur », ou encore « le compilateur n'aime pas la ligne 27, il me donne cette erreur » sont nettement mieux.

1 : Cela vous rappelle peut-être vos cours de français de sixième. Schéma narratifs, tout ça.

Comprendre ce qui se passe

Après avoir constaté le problème, il faut maintenant l'identifier clairement, le comprendre. Pourquoi ça plante ? Le message d'erreur est une source précieuse d'indices, aussi abscons qu'il paraisse. En effet, même s'il est écrit en anglais alors que vous ne parlez pas cette langue², vous pouvez le copier/coller sur un moteur de recherche, faire une recherche en français, et voir les résultats que vous trouvez.

Vous n'aurez pas forcément la solution à votre problème en faisant cette recherche, mais, à ce stade, ce n'est pas le but. Pour le moment, on veut comprendre d'où vient le problème, ou au moins trouver une liste de causes possibles. C'est quelque chose qui doit absolument figurer dans votre topic : « je pense que le problème vient de là », « après quelques recherches, j'ai vu que les causes possibles sont un mauvais réglage ou un manque de mémoire ».

Ces deux premières étapes sont vitales pour votre topic, pourtant, trop souvent, on voit l'une ou l'autre - parfois les deux - négligées par les posteurs. Notez bien que tous ces conseils impliquent que vous devez poster le code source, votre environnement³, le message d'erreur ou la description détaillée du comportement indésirable, et aussi ce que vous pensez du problème et ce que vous avez trouvé dessus⁴.

Premiers pas vers la résolution

Se forcer à faire tout ce travail a deux grands avantages : il vous fait travailler sur le problème, ce qui vous permet de mieux le comprendre, et donc potentiellement de mieux vous débrouiller ; et il montre aux gens qui vont lire votre post que vous avez la volonté de résoudre le problème, que vous ne voulez pas que tout vous tombe tout cuit dans la bouche, que vous avez bien compris qu'un forum n'est pas une hotline - à moins que vous ayez payé l'accès.

Le premier point est important car il est le premier pas vers la résolution du problème. Une fois celui-ci bien identifié et compris, l'étape suivante, c'est d'essayer des solutions. Combinez les recherches sur le web avec des essais personnels, et, à chaque fois, expliquez ce que vous avez tenté, pourquoi, et ce qui s'est passé. En effet, il est possible qu'un internaute plus expérimenté puisse conclure de vos expériences des choses qui vous échappé. Plus généralement, plus les autres auront d'informations sur votre problème, mieux ce sera.

Vous pouvez ainsi remarqué qu'à chaque fois que vous travaillerez sur un problème, vos efforts « compteront double » : ils vous seront bénéfiques à long terme, puisque vous aurez appris quelque chose (même si vous ne vous en rendez pas compte sur le moment), et ils sont bénéfiques à ceux et celles qui veulent vous aider sur le court terme, donc indirectement à vous-mêmes maintenant.

Sont-ils tous aigris ?

En suivant la méthode de « la feuille de route », vous n'aurez probablement pas de réponses sèches ou blessantes à vos topics. Vous ferez peut-être des erreurs au début, mais on verra que vous y avez mis de la bonne volonté, et on ne vous en tiendra pas rigueur.

Pourtant, bien souvent, on voit des membres « agressés » par des posteurs expérimentés. « Ça ne coûte rien d'être gentil ! ».

Le fait est que, comme vous vous en serez aperçu en rédigeant votre topic, faire un bon post est quelque chose de long et de difficile. Même lorsqu'on a la réponse à la question, il n'est souvent pas évident de l'expliquer clairement, en se plaçant dans le contexte du posteur, de chercher les liens qui vont bien, et ainsi de suite. Du coup, les gens, qui ne sont après tout pas payés, n'accepteront de rédiger des bons posts qu'aux questions dont ils pensent qu'elles en valent la peine.

Ainsi, passer un quart d'heure à expliquer qu'il faut régler son compilateur correctement, avec captures d'écran et liens, en sachant pertinemment que la réponse est dans la FàQ et dans 42 autres topics du forum, est impensable pour la plupart des posteurs.

Ainsi, même si on y pense pas forcément, aller retrouver une page web que l'on a pas visité récemment, puis copier/coller l'URL et faire un lien, c'est relativement long et chiant. Du coup, même un post contenant juste : « déjà traité » avec deux liens vers des topics similaires est à prendre en considération, et, malgré les apparences, est la pour vous aider. Ces topics n'abordent très probablement pas un problème exactement identique au votre, certes. Mais, la plupart du temps, ce genre de réactions survient lorsque le topic ne contient pas de passage « voilà les causes possibles et autres problèmes qui ressemblent un peu que j'ai trouvé ». La réaction du posteur est alors naturelle : fournir des causes possibles et d'autres problèmes qui ressemblent un peu, puisque c'est ce qui manque. Et quand c'est le 17^ème topic sur le sujet auquel on répond, on en a marre d'être poli et gentil.

Conclusion

Pour conclure, gardez à l'esprit trois principes de base : - essayez de comprendre le problème par vous-mêmes, et montrez-le, essayez de le résoudre par vous-mêmes, et montrez-le, - ne vous sentez pas agressé si vous n'obtenez pas la réponse attendue. Contre toutes les apparences, les gens qui postent sont là pour vous aider.

Je finis donc sur une phrase de LoupSolitaire : Mon but est de t'aider à résoudre ton problème, pas d'être sympa.