Licence CC BY

Culte du Cargo et développement informatique

Publié :
Auteur :
Catégories :
Temps de lecture estimé : 2 minutes

Connaissez-vous le Culte du Cargo ? Saviez-vous que ça s’applique à l’informatique – et probablement à d’autres corps de métier ?

Le Culte du Cargo

À la fin du XIXème et jusqu’au milieu du XXème siècle, la Mélanésie se vit envahir par des troupes américaines ou japonaises. Ces occupants étaient ravitaillés par avions-cargos : un opérateur radio appelait, et un ravitaillement arrivait.

Les Mélanésiens, à qui on avait rien expliqué de tout ça et peu au fait de la technologie, étaient donc incapables de comprendre la causalité réelle du lien entre les opérateurs radio et l’arrivée du ravitaillement : l’explication la plus logique pour eux était que les actions effectuées par les opérateurs étaient une espèce de rite plus ou moins divin, qui permettait l’arrivée du ravitaillement.

Conséquence : en reproduisant ces rites – mais sans matériel réel ni lignes de ravitaillement – certains ont pensé pouvoir faire apparaître les fameux avion-cargo. Évidemment, ça n’a jamais fonctionné.

Plus de détails disponibles sur Wikipédia.

Dans l’informatique

Le terme est aussi utilisé de façon plus générique pour décrire les cas où quelqu’un essaie d’appliquer une action à une situation pour obtenir un résultat précis, mais sans comprendre correctement ni l’action, ni la situation, ni la corrélation entre tout ça. L’utilisateur espère donc que son action va résoudre de manière plus ou moins magique ou divine son problème.

L’exemple informatique typique, c’est de copier un code sur Internet et de le coller bêtement dans un programme en espérant qu’il fasse ce pour quoi on en a besoin. Mais ça peut être plus subtil que ça, et s’applique à peu près à toutes les situations où quelqu’un tente de résoudre un problème en appliquant une méthode connue, alors qu’il ne comprends ni la cause du problème, ni même ce que fait réellement la méthode.

C’est un cas assez fréquent et problématique, surtout quand « parfois ça marche ». Parmi les effets de bord rencontrés, on trouve :

  • Beaucoup de temps perdu à essayer des « solutions » inexistantes.
  • Présence de code et/ou configurations « magiques » qui ne servent à rien (mais qui sont à maintenir, et susceptibles de provoquer des bugs).
  • Si par malheur la solution fonctionne mais à cause d’une partie du « rituel », ça peut être long et compliqué d’extraire la solution minimale réelle.
  • Le jour où on sort du cas exact où la solution fonctionne réellement, c’est catastrophique parce que l’on ne sait pas pourquoi on est sorti du cas fonctionnel ni comment y revenir alors même qu’on pensait maîtriser le sujet.
  • Si le rituel est foireux, on peut commettre des erreurs en pensant bien faire.

S’en débarrasser

Une fois le Culte du Cargo identifié, il faut s’en débarrasser. Ma méthode personnelle, c’est de commencer par : « Est-ce que la personne comprends ce qu’elle fait ? ».

Si la réponse est non, c’est généralement assez facile de remédier au problème. Ou au moins d’avoir la volonté de remédier au problème, après c’est une question de temps, de moyens et de motivation.

Mais parfois, on obtient un « oui » (alors que d’évidence, non), un « ben… », un « on a toujours fait comme ça » (la pire des réponses, surtout en informatique). Et là, le travail de psychologie commence…


Et vous avez-vous été confronté à un Culte du Cargo dans votre vie ?
Dans quel domaine ?
Comment vous en débarrassez-vous ?



Icône CC BY 3.0 Tim Ross

8 commentaires

« on a toujours fait comme ça » (la pire des réponses, surtout en informatique)

Quelque chose qu’on appelle dans certaines situations « normalisation de la déviance ». Deux super lectures à ce sujet, une principalement à propos d’informatique : https://danluu.com/wat/ 1, une nettement plus longue et dont le lien avec le sujet ne me revient pas précisément (je l’ai classé comme ça mais je saurais plus dire si c’est parce qu’il est devenu normal de pas savoir piloter en manuel, ou normal de pas piger les indicateurs électroniques, ou autre2) mais qui parle d’aviation : http://www.vanityfair.fr/actualites/international/articles/vol-af-447-rio-paris-reconstitution-des-minutes-qui-ont-precede-le-crash/23618


  1. Le cargo culting a bien sa place dans l’article également, par exemple là : «This kind of diffusion happens for technical decisions, too. Stripe built a reliable message queue on top of Mongo, so we build reliable message queues on top of Mongo. It’s cargo cults all the way down.» 

  2. edit: je crois que ça m’est revenu, en cas de décrochage une alarme se déclenche, mais cette alarme s’arrête si l’appareil est trop incliné, genre proche de la verticale ou pas trop incliné mais en ~chute libre, parce que le détecteur de décrochage ne se fait pas confiance. Du coup quand l’appareil à commencé à décrocher, il a décroché jusqu’à ce qu’au point où l’alarme s’arrête et les pilotes se disent "nan c’est bon on est pas en train de tomber, sinon on mettrait les gaz, là ça va". 

Édité par cepus

+7 -0

Mon plaisir, ce sont des "traits" intéressants de notre champ professionnel.

Je pense qu’on cargo culte tous, pas forcément tous à grande échelle, mais on le fait tous. Je pense plus particulièrement à ce qui est config et tooling quand on est développeur. Si t’es développeur et que tu cargo culte dans ton code, que ce soit des "feintes" ou des patterns, pas bien. Pas de ça dont je parle.

Exemple : Quand je traine dans les dotfiles de quelqu’un d’autre et que je prends un bout de config zsh, vim, weechat, souvent je ne comprends pas exactement le bout de script que je prends, donc j’isole pas parfaitement la partie qui m’intéresse. Ça pose parfois problème plus tard.

Peut-être que tenter d’isoler les choses est justement un bon moyen d’éviter de cargo culter ?

Je pense qu’on a tous à un moment ou un autre utilisé des incantations magiques. Copier-coller des bouts de Makefile qui contiennent des target PHONY et des lignes qui commencent par - ? Assembler des bouts de bash sans savoir précisément qu’est-ce qui fait quoi ?

1
2
3
4
#!/usr/bin/env bash
set -euo pipefail

. foo.sh

Je crois qu’à l’époque où je copiais des bouts de DHTML pour mettre de la neige sur ma page perso lycos.fr, quand ça marchait pas j’enlevais tout ce que je pigeais pas, puis y’a rien qui marchait, puis je rajoutais petit à petit ce que j’avais enlevé ce qui me permettait de reverse engineerer l’effet de chaque ligne. Je pense que c’est en partie comme ça que j’ai appris à programmer et que c’est pas con bien qu’inefficace ?

En tout cas c’est une bonne idée d’exposer les gens à des "phénomènes" certainement connus mais pour lesquels ils ne savent pas forcément qu’on a un nom.

+1 -0

Après il me semble illusoire de vouloir une compréhension profonde de tout ce qui nous entoure. Même dans nos développements logiciels.

Je veux dire, je code régulièrement dans le noyau Linux qui est un monstre de complexité si on souhaite comprendre en détail son fonctionnement. Et je pense que seuls quelques personnes dans le monde en ont une compréhension profonde et globale.

C’est le concept d’encapsulation qui est au cœur de l’automatisation. On délègue de nombreuses tâches complexes qu’on ne comprend pas et on espère que les entrées / sorties que l’on a apprise (via la documentation ou une formation) suffise. Mais parfois non, des détails internes non réellement exposés restent utiles mais sont souvent cachés voire difficile à assimiler. Du coup, paf, tu es bloqué dès que tu sors un peu du cadre prévu initial sans que tu puisses t’en rendre compte.

Dans le cas des avions de lignes, il est je pense douteux de croire qu’un pilote peut avoir aujourd’hui une maîtrise complète de l’appareil, surtout quand il sort des sentiers battus. Il faut les former pour qu’ils en aient une connaissance suffisante pour la plupart des cas mais c’est tout.

Ce qui est étonnant, c’est que les pilotes (dans le cadre du vol documenté plus haut) étaient isolés. Pas de contacts avec des gens au sol avec potentiellement un référent technique et des ingénieurs du constructeur pour les aider. Technologiquement cela me semble possible et cela pourrait permettre de compenser le manque de compréhension des pilotes dans certains cas.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+1 -0

Je crois qu’à l’époque où je copiais des bouts de DHTML pour mettre de la neige sur ma page perso lycos.fr, quand ça marchait pas j’enlevais tout ce que je pigeais pas, puis y’a rien qui marchait, puis je rajoutais petit à petit ce que j’avais enlevé ce qui me permettait de reverse engineerer l’effet de chaque ligne. Je pense que c’est en partie comme ça que j’ai appris à programmer et que c’est pas con bien qu’inefficace ?

J’ai souvent fait ça aussi. C’est terriblement inefficace, mais très formateur. J’imagine donc qu’il ne faut pas tout le temps appliquer cette méthode, mais de temps en temps c’est utile.

Après il me semble illusoire de vouloir une compréhension profonde de tout ce qui nous entoure. Même dans nos développements logiciels.

C’est clair. En fait, dans nos boulots, il y a un niveau de compréhension de ce qu’on fait : le but du jeu, c’est de réussir à comprendre suffisamment ce qu’on fait pour éviter d’y aller par magie et hypothèses théoriques, mais de garder un niveau d’abstraction assez élevé pour éviter de perdre du temps et de l’énergie à maîtriser des détails inutiles.

Donc, on se retrouve en permanence à devoir évaluer si on comprends assez bien ce qui se passe pour éviter de faire des conneries ; et à devoir évaluer si on a besoin de creuser tel ou tel point. Sachant que tout ça c’est des fonctions à hypothèses et risques : le seul moyen de savoir si on avais vraiment besoin de comprendre un sous-système… c’est de le comprendre. Donc on doit faire des hypothèses, et prendre le risque de se planter – et la question n’est pas de savoir si on va se planter mais quand.

De mon point de vue, le problème apparaît dans deux cas :

  1. La fonction d’évaluation du risque est clairement foireuse (donc, soit on fait plein de trucs magiques, soit on perds un temps énorme sur des détails).
  2. Les gens qui refusent de se poser la question : « est-ce que je comprends ce que je fais, et est-ce que j’ai besoin de mieux le comprendre ? »

C’est un peu décousu, mais il y aurait de quoi faire plusieurs articles sur le sujet.

Un autre cas de cargo culting qu’on n’a pas encore évoqué il me semble c’est la perpétuation de vieux mythes.

J’avais une histoire en tête à base de toast dont quelqu’un coupait les bords avant de toaster mais je l’ai pas retrouvée, après beaucoup de recherche j’en ai trouvé des variantes et découvert que c’est une ~vieille fable/blague/anecdote. Voici une traduction d’une version trouvée ici, il y en a plusieurs à cette adresse :

La jeune mariée cuisine pour la première fois un repas pour son mari et s’essaie à la fameuse recette de rôti de sa mère, coupant les deux extrémités du rôti comme sa mère l’a toujours fait. Le mari trouve le rôté délicieux mais demande "Pourquoi est-ce que tu as coupé les deux bouts du rôti ? C’est le meilleur !" Elle répond : "Ma mère a toujours préparé le rôti comme ça".

La semaine suivante, ils se rendent chez sa grand-mère, et elle prépare le fameux rôti, coupant à nouveau les deux extrémités. La jeune mariée, certaine de passer à côté d’un détail crucial, demande à sa grand-mère pourquoi elle enlève les deux bouts. La grand-mère lui répond : "Ma chérie, c’est le seul moyen pour qu’il entre dans le plat !".

Pour illustrer le rapport avec l’informatique, j’ai vu des gens ici sur les forums expliquer qu’il fallait toujours faire :

1
2
const l = xs.length
for (let i = 0; i < l; i++) {

au lieu de :

1
for (let i = 0; i < xs.length; i++) {

parce que comme ça, la condition i < xs.length ne calculerait pas xs.length à chaque itération de la boucle.

C’était peut-être vrai il y a 10 ans, mais de nos jours c’est un conseil aussi avisé que s’entourer de cactus pour bloquer les ondes électromagnétiques.

Pas facile de convaincre les gens que ce qu’ils ont appris n’est plus valable, d’autant plus quand ils ne sont pas capables de vérifier par eux-mêmes parce que vérifier ça n’est pas possible avec leurs outils habituels.

+4 -0

Perso, je vois des occurrences de ce biais régulièrement dans mon équipe, appliqués le plus souvent par manque d’expérience face à certaines problématiques. Pour y faire face en tant que tech lead, j’ai adopté une stratégie dans laquelle j’accepte de perdre un peu de temps et d’efficacité en laissant les gens se planter et en rattrapant le truc avant qu’il ne soit trop tard, pour qu’ils comprennent leur erreur et ne la reproduisent plus sur le long terme.

Dernier exemple que j’aie en tête : on avait il y a pas très longtemps une tâche où l’on avait besoin de générer une sortie en HTML, mais dans un format hyper linéaire. Le collègue qui a pris la tâche est parti en disant "on va utiliser jinja2 !". En soi, ce n’est pas déconnant, puisque jinja2 est le moteur de template en Python, mais je pressentais que la solution n’était pas si automatique que cela, et qu’une bête concaténation de chaînes serait à la fois plus simple et plus efficace dans ce cas précis.

Au lieu d’en discuter pendant des plombes, parce qu’il n’est jamais évident de justifier de réinventer la roue (surtout auprès d’un dev Python), j’ai préféré dire : "ok, moi je le ferais pas comme ça et je me contenterais d’un ''.join(...), mais utilise jinja si tu le sens, tant que ton code est clair et que ça marche, ça me va".

Une demi-journée plus tard, mon collègue est revenu me voir : "bon, en fait, ça complique pas mal le code de faire rentrer mes données dans un moteur de templates". C’est là que je lui ai re-proposé ma solution. Je sais que dorénavant ce collègue ne fera plus automatiquement l’association "génération de HTML <-> moteur de templates". On y a perdu une demi-journée (ce qui est peanuts, objectivement), mais la leçon a été acquise.

En ce qui me concerne, j’estime que ce petit sacrifice, qui prend quand même du temps, vaut largement le coup par rapport aux alternatives (par exemple, imposer la solution, même en l’expliquant).

Édité par nohar

I was a llama before it was cool

+5 -0

Merci beaucoup pour l’article, très intéressant, et les remarques associées.

Je pense qu’on a tous des exemples de cargo culting dans notre quotidien professionnel.

Je rajouterais une information / un lien à établir : le lien entre cargo culting et dette technique.

Ca n’est pas explicitement relié dans ton article, et pourtant il faut l’expliciter : le cargo culting est un ajout direct (et énorme) de dette technique dans un projet.

Quand on parle de dette, on parle de tous ces petits (ou pas) problèmes qui nous empêchent d’avancer au rythme où on aimerait. On dit souvent que pour implémenter une nouvelle fonctionnalité, ouvrir un service à l’extérieur etc. on doit "payer la dette". Et là-dedans, le cargo culting joue un rôle majeur : s’il est nécessaire d’implémenter une nouvelle fonctionnalité sur base de l’existant, qui fonctionne de façon un peu magique (une conf qui traîne, des "magic numbers" ça et là, etc.) il y a de fortes chances que la dette à payer s’en voit fortement augmenter. Cf. le "mais ça marchait bien jusque là, pourquoi ça fonctionne moins bien maintenant".

C’est d’autant plus problématique que c’est de la dette quasiment impossible à mesurer. Autant certains outils d’analyse peuvent remonter des problèmes engendrant de la dette technique (Sonar pour pas le citer) : code difficile à appréhender, refactoring nécessaire, bugs identifiés (file handlers jamais fermés), etc. autant ce type de problème n’est pas remonté. C’est ce que j’appelle de la "dette cachée" ou "dette latente" et elle est d’autant plus difficile à expliquer. "Mais pourquoi ça a pris 10 jours à implémenter ??" "Parce qu’on a mis les mains dans un truc incompréhensible et on a failli tout casser".

Y’a souvent une forme de mysticisme derrière tout ça, et le terme "culte" colle vraiment bien au problème. Le fait d’en être conscient, d’en parler, et de mettre un mot derrière ça est sans doute une bonne première étape. Pas suffisante, mais vraiment nécessaire.

Merci pour ça.

Happiness is a warm puppy

+3 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte