Tricher

Lors d’une formation sur l’administration système GNU/Linux il y a quelques années, le formateur nous avait lancé un petit défi. Il passait sur chacun des ordinateurs à disposition sur lesquels nous travaillions, modifiait 2-3 choses afin de les faire tomber en panne. Un exemple basique pour vous imaginer le truc : Il mettait de la merde dans /etc/fstab puis le système ne démarrait plus correctement au reboot. Évidemment nous ne savions pas ce qu’il avait fait, il fallait résoudre le problème.

Cet épisode m’a profondément marqué, j’ai résolu le souci en quelques minutes alors que le formateur n’avait pas encore fini le tour de la classe et que chacun galérait. Il était étonné mais surtout vexé, pour lui j’avais triché, je n’avais pas respecté les consignes.

Je peux comprendre son point de vue, pour lui j’aurais dû diagnostiquer le problème, vérifier d’où il provenait, émettre une hypothèse, consulter les logs, etc. Une sorte de démarche noble, le cheminement intellectuel d’un ingénieur. Personnellement une fois le système monté en rw, j’ai lancé un find pour trouver les 10 derniers fichiers modifiés, corrélé le problème avec le probable fichier source du dysfonctionnement, remis les bonnes valeurs et rebooté. Ce fut rapide.

J’avais triché parce que je n’ai pas suivi « le bon chemin », la bonne méthode. Peut-être est-ce comparable à l’élève qui donne le bon résultat mais n’est pas capable de correctement expliquer le calcul sur une question de maths ?

Encore aujourd’hui je trouve sa remarque très déplacée. Le système ne démarre pas correctement, un fichier a probablement été modifié, quels sont les derniers fichiers modifiés, celui-ci au regard du problème et de mes connaissances me semble un bon candidat, je le modifie, je teste/reboote, problème résolu.

Mais je sais où est le nœud de notre désaccord. Je ne serai jamais un ingénieur alors que ce titre est présent sur mes fiches de paie depuis mon précédent job. Je suis un technicien. J’ai appris sur le tas. Un problème se dresse devant moi, je deviens un bulldozer fonçant dessus à la vitesse d’un avion de chasse.

Pour moi il n’y a pas de règles, pas d’honneur, pas de respect à avoir (pour qui ? la machine, le cheminement intellectuel, la collecte méthodique et ordonnée des informations ?), tous les coups sont permis. Mon objectif est la résolution du problème dans les meilleures conditions, en général le plus rapidement possible. Je me fous du comment, du pourquoi, mon unique but est le résultat. J’ai passé la plus grande partie de ma vie professionnelle à dépanner des utilisateurs. Un utilisateur rencontrant un problème ne peut pas travailler, il est bloqué, plus je le débloque vite, plus vite il peut retravailler. Je place l’utilisateur avant (en premier), toujours. La collecte des informations, une démarche intellectuelle/organisationnelle après.

Dans mon job actuel on me demande de déterminer comment et pourquoi un problème est arrivé, aller plus loin, résoudre le problème à la racine. J’épluche les logs, je tente de reproduire, je ponds un fichier de config de 3 lignes au bout de 2 jours. Je le fais, je comprends et respecte parfaitement le besoin, les consignes.

En vérité je ne triche pas, je m’adapte au contexte. Tantôt brutal et rapide (technicien), tantôt précis et méthodique (ingénieur). J’ai vu des techniciens penser comme des ingénieurs, beaucoup plus rarement des ingénieurs penser comme des techniciens. Ce jour-là l’ingénieur m’a pris de haut.

Déjà 8 avis pertinents dans Tricher

  • jsbjr
    Dans ce cas ton enseignant voulait vous mettre en situation. Il a créé un scenario: paf machine cassée démerde toi. Par un raisonnement meta tu a cassé son scénario i.e. en utilisant des informations que tu n’aurais pas eu en situation réelle selon lui. Il est normal qu’il soit un peu vexé.
    Mais ton cas on peut objecter que si une machine cesse de fonctionner brutalement ça peut être a cause d’une modification malheureuse de sa configuration. Ton approche me semble valide dans ce scenario.
  • Gary
    Hello ,

    Je rejoins ce que dit jsbjr, les informations que tu as eu en plus sont que: Tu es dans un scénario, le sabotage vient d’avoir lieu.
    Si on reprend ta méthode, en pratique elle n’aurait très probablement pas fonctionnée. Imaginons que le problème ai lieu suite à une update foireuse, tu n’aurais été informé qu’au prochain redémarrage de la machine, peut être 2 mois plus tard.

    Il aurait pu faire n’importe quel sabotage sur des fichiers, ton raisonnement méta aurait fonctionné. Hors en pratique, aujourd’hui, as-tu comme réflexe de faire un find à chaque disfonctionnement d’une machine?

  • alterlibriste
    Article super intéressant et j’approuve ta méthode (même si je suis ingénieur et pas informaticien pour le coup). Effectivement, tout dépend si le but est de comprendre ou de résoudre le problème, sachant que lorsqu’on a trouvé la modif faite, on comprend ce qui ne marche plus même si la façon de le trouver n’est pas intellectuelle mais empirique.
    En fait, tu as « triché » autant que le gamin qui résout un labyrinthe (trouver lequel des 3 chemins arrive à la sortie) en partant de la fin. Ce n’est pas en faisant des hypothèses que l’on vérifie mais en partant de la solution et c’est bien plus efficace.

Les commentaires sont fermés.