Connexion
Abonnez-vous

Selon une étude, près de 10 % des ingénieurs logiciels « ne font pratiquement rien »

Le 27 novembre à 15h30

Sur son profil LinkedIn, Yegor Denisov-Blanch explique avoir abandonné l'école à l'âge de 14 ans, avant d'apprendre, en autodidacte, à coder en PHP, ce qui lui aurait permis de gagner 500 000 dollars à l'âge de 18 ans. Il aurait ensuite dépensé 250 000 dollars pour retourner à l'université, en sautant cinq classes, avant de devenir chef de cabinet du PDG de la région EMEA et transformation numérique/stratégique de DHL en 2017 puis, depuis 2022, chercheur à Stanford, où il étudie la productivité de l'ingénierie logicielle.

Dans un thread sur X.com, il explique disposer de données sur les performances de plus de 50 000 ingénieurs dans des centaines d'entreprises ayant accepté de partager leurs dépôts Git privés avec son équipe, et avance que « ~ 9,5 % des ingénieurs logiciels ne font pratiquement rien ». Ses conclusions (qui restent à confirmer) vont certainement faire parler et soulèvent en tout cas des questions, y compris sur la méthodologie.

Quoi qu’il en soit, son équipe travaille sur un modèle qui quantifie la productivité en analysant le code source de dépôts Git, et en simulant un panel de 10 experts évaluant chaque livraison à travers de multiples dimensions. Or, ils ont constaté que 14 % des ingénieurs logiciels travaillant à distance ne font presque pas de travail (et qu'ils qualifient dès lors d' « ingénieurs fantômes »), contre 9 % dans des rôles hybrides et 6 % au bureau.

« Bien qu'il s'agisse d'une méthode imparfaite pour mesurer la productivité », précise-t-il, ils ont aussi découvert que « ~58% des personnes interrogées effectuent moins de 3 commits/mois ».

Ils ont ensuite cherché à mesurer ce que cette absence de productivité coûterait à leurs employeurs respectifs, et estimé que les 17 100 « ingénieurs fantômes » d'IBM (soit 9,5 % de ses 180 000 ingénieurs) lui coûterait 2,5 milliards de dollars (sur la base d'un coût annuel de 150 000 dollars par ingénieur), les 10 450 de Microsoft 1,5 milliard, les 9 500 d'Oracle et Google 1,4 milliard.

« En supposant de manière prudente que seulement 6,5 % des ingénieurs dans le monde sont improductifs (au lieu de 9,5 %), cela représente 90 milliards de dollars effectivement gaspillés » par 1,8 million d'ingénieurs fantômes dans le monde entier, que Yegor Denisov-Blanch voudrait voir licenciés.

Ils proposent aux entreprises et organisations employant « idéalement » plus de 50 ingénieurs de participer à leur enquête en partageant avec eux leurs dépôts Git, ce qui permettrait aux employeurs d' « obtenir une visibilité granulaire sur les résultats de vos processus d'ingénierie », et de « réduire potentiellement les coûts », en identifiant leurs propres « ingénieurs fantômes ».

En réponse à des commentaires ironisant sur les « managers fantômes », le chercheur rétorque que « Quelque chose me dit que le chiffre est peut-être supérieur à 9,5 % ! », tout en précisant qu'ils ont aussi exclu les ingénieurs, par ailleurs managers, de leur base de données, ainsi que toute personne n'écrivant pas de code.

Il précise aussi que les commits ne leur servent pas de mesure de la productivité, et renvoie à un article de recherche publié en septembre dernier détaillant leur méthodologie, en vue de « Prédire les évaluations des experts dans les revues de code logiciel ».

Le 27 novembre à 15h30

Commentaires (65)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Hmmm... Je lisais des réactions sur cette étude hier et ...
- quid de la méthodologie ?
- quid de la prise en compte de l'encadrement (un bouffe temps comme pas permis) ?
votre avatar
Et des RCA sur les pb client, qui peuvent être très consommateurs, des phases spécification etc... Ne se baser que sur les commit c'est limité. Puis on peut faire un commit unique d'un gros boulot cassant si on le split... ou des dizaines pour des petites merdes qu'une IA aurait pu coder.
Maintenant, git est peut-être aussi un peu la source du problème: Un peu pénible, conflits quasiment inévitables même sur des truc disjoints... Courant de passer beaucoup plus de temps à livrer qu'a avoir développé/testé ce qu'on livre. D'une manière générale j'ai essentiellement connu des système de gestion de conf centralisés avant git qui posaient certes des pb de réplication à leurs admins mais en comparaison très peu aux développeurs. Git a inversé l'affaire.
votre avatar
Il n'est pas vraiment question d'un système de gestion de conf précis, juste de commits.

Et, même si ca n'a pas grand chose à voir avec le sujet, je suis en désaccord avec toi: "j'ai essentiellement connu des système de gestion de conf centralisés avant git qui posaient certes des pb de réplication à leurs admins mais en comparaison très peu et autant aux développeurs. Git a inversé amélioré l'affaire" (pour moi). C'est très subjectif et dépendant du contexte.


Pour en revenir au sujet, la métrique "nombre de commits" est très mauvaise, même si elle m'avantage personnellement, étant un grand "committer" de nature et n'aimant pas trop "squasher". Je bats tout le monde dans la boite. Je vais me servir de cet argument pour ma prochaine augmentation :)
votre avatar
Ils ont juste l'air de dire que pas de ligne de code sur les dépôts de l'entreprise = ingé qui fait rien
votre avatar
ce fut la méthode de musk pour faire le ménage des dev à tweeter : il a gardé ceux qui pissent le plus de code.

enjoy

j'appelle ça un torchon.
votre avatar
C'est moi où toute les parties conception, échanges sur les tickets, partage de connaissances, aide de collègues sont oubliées ?
votre avatar
et débogage, car des fois changer un caractère peux prendre plusieurs heures d'investigations.
votre avatar
Ça, ça pourra se voir dans le commit.
votre avatar
Et toute la dimension humaine (conduite de projet, du changement, psychosociologie de l'entreprise) ainsi que la veille technologique (d'ailleurs, c'est pas un peu ce qu'on fait ici sur nos heures de boulot ? :3)
votre avatar
près de 10 % des ingénieurs logiciels « ne font pratiquement rien »
que dire de 90% des CEO...
votre avatar
Easy tiger.
votre avatar
Si un jour tu trouves un CTO qui fournit une roadmap techniques applicables tu me préviens aussi :)
Ou des équipes sécurités qui fournissent des recommandations et pas juste des "coups de tampons" (et encore, quand il y en a un...),
et soyons fous, des responsables contrats qui ont des templates standardisés avec les clauses juridiques applicables de l'entreprise !
votre avatar
Chez nous la C-suite a fait une roadmap... mais elle est secrète. Ils ne peuvent pas nous la dévoiler.
Des génies !
votre avatar
On voit qu'il y a beaucoup d'opérationnels. Dans mon secteur qui ne sera jamais en crise, c'est pas gros branlage de mammouth mais en terme d'efficacité opérationnelle, c'est pas ça du tout.
votre avatar
Bouah, je pense que c'est pareil dans tous les services :
Trouver des RH qui fassent vraiment de la gestion de l'humain et pas juste de l'administratif, c'est exceptionnel.
Ou des internes dans des grosses boites qui ne soient pas juste des boites aux lettres entre les services qui font passe-plat pour les externes.
votre avatar
Quel balance ce Git....
votre avatar
J'ai toujours trouvé suspecte cette commande "blame" de git, qui balance celui ou celle qui devra porter le bonnet d'âne.
votre avatar
J'avoue que le nom de la commande me semble mal choisie, car très violente... Mais bon, sur une techno appelée "connard"...
votre avatar
svn blame existait déjà et la commande commit indique qu’il faut commettre (le méfait ?) donc ça reste dans la logique (oui, le verbe commit a plusieurs sens mais quand même).
votre avatar
Côté balance, Musk se défend (déjà) bien : Elon Musk attaque les « faux emplois » de fonctionnaires… vague de peur dans les administrations
Sur X, le codirecteur de l’Agence pour l’efficacité gouvernementale a partagé des publications révélant leurs noms, fonctions et salaires
votre avatar
Le nombre de commit est une mauvaise mesure !
Un collègue à qui l'on reprochait justement de faire "pas assez de commit" (alors qu'il était excellent) a écrit un bot pour faire des commits inutiles assez régulièrement, et du coup il est remonté dans l'indicateur inutile. CQFD
votre avatar
C'est comme les boites qui regarde l'heure des commits pour savoir si tu travailles bien. Ils ne doivent pas connaitre l'option --date 🙄
votre avatar
Je ne connaissais pas perso !
votre avatar
Mois non plus :)
votre avatar
La méthodologie ne s'appuie pas uniquement sur le nombre de commits : le graphe [[https://next.ink/wp-content/uploads/2024/11/StanfordCommits.png]] indique la répartition du nombre de commits/mois pour les "ingénieurs fantômes".
Maintenant, il manque en effet la description de la méthodo (pour pouvoir la critiquer) ... :D

Ceci dit, je suis passé par plusieurs entreprises ces dernières années, et dans toutes, une certaine proportion des développeurs (10% me paraît une bonne estimation) ne produisait pas grand chose (en tenant compte des rituels, des ateliers de conception, du run, etc.) ...
Pour certains, un changement d'orientation professionnelle aurait été une bonne idée.

Par ailleurs, j'ai croisé aussi beaucoup de développeurs qui "produisaient" beaucoup, mais la qualité de la production n'était pas exemplaire.

Mais tous les autres, je les aimais bien :D :love:
votre avatar
Oui tout à fait, une estimation "à la louche" de 10% est tout aussi valide !

Un jour mon chef vient me voir et me dit : quand auras-tu corrigé le bug ?
Je lui réponds : chef, écoute, je ne sais pas encore d'où ça vient et je cherche. Quand j'aurai trouvé d'où ça vient, peut-être je pourrais te donner une estimation du temps de correction. Maintenant si tu veux m'aider à chercher, ça ira plus vite !

Du coup il est parti...

Mais il était aussi réaliste, il avait fait du code avant d'être chef.
Chef : Je sais que mon code n'était pas terrible.
Moi : Oui effectivement, mais enfin il a au moins le mérite d'exister et de fonctionner... la plupart du temps. :-)
votre avatar
Et moi je suis dans l'industrie et on trouvera sans probleme 10% d'inefficace en mécanique/ usine aussi !

Je crois que même chez les fourmies c'est prouvé qu'il y a une part d'inutiles alors bon, imaginez chez les cigales !
votre avatar
30% chez les fourmis et les abeilles de oisives et contre-productives.
On a aussi prouvé la mauvaise foi et la fainéantise chez les abeilles si pas assez de récompense.
votre avatar
Non, c'est une très bonne mesure voyons. Il y a peut-être un biais: tous les bugs sont dûs à ceux qui font des commits.
Et de même, plus tu fous la grouille avec tes bugs, plus tu peux commiter tes corrections. Ca c'est bosser.
votre avatar
C'est quoi cette méthodologie de merde ? (je mesure l'usage de la vulgarité ici)

Le travail d'ingénieur ne se résume pas qu'à réaliser des commits. J'ai des périodes où je fais très peu de commits, car je passe plus de temps en analyse, sur un poc ou en calls. La "productivité" ce n'est pas pisser du code pour avoir de beaux chiffres à afficher.

Ça tombe bien, car je suis en train de lire le dernier livre de Cal Newport, Slow Productivity, et c'est exactement le type d'analyse qu'il critique dès le début (j'invite d'ailleurs à lire ses différents livres, très enrichissants, voire limite philosophiques, à ceux qui ne le connaissent pas).
votre avatar
Je vais paraphraser ce que SebSauvage a écrit : https://sebsauvage.net/links/?PGtm_A

La méthode qui consiste à évaluer la productivité d'un "ingénieur" sur la base uniquement du nombre de lignes de code publiées a déjà été remise en cause à plusieurs reprises comme dans l'exemple donné par SebSauvage en 1982 dans l'équipe qui travaillait sur le Lisa.

Pire, une des conséquences d'un tel management ne peut que produire à terme du mauvais code.

CQFD.

EDIT: la question du timing d'un tel article me rend perplexe.

En effet, c'est précisément à l'heure où la Silicon Valley fait face à une conjecture économique difficile (sans précédent ?) qu'il est publié.

À l'heure où le dégraissage est en cours, cet article arrive à point nommé, n'est-il pas ?!

C'est comme si l'on recherchait des justifications pour les futurs licenciements ...
votre avatar
Sans parler du fait que le gars explique que c'est dans ceux qui bossent en télétravail que le pourcentage est le plus élevé (quand tous les gros veulent faire revenir les gens au bureau).

Et que le mec essaye de vendre sa soupe au passage.

Bref pas convaincu.
votre avatar
Il précise aussi que les commits ne leur servent pas de mesure de la productivité, et renvoie à un article de recherche publié en septembre dernier détaillant leur méthodologie, en vue de « Prédire les évaluations des experts dans les revues de code logiciel ».

Si l'objectif n'était effectivement pas de mesurer la productivité via le nombre de lignes de code ou de commit, il n'aurait pas été nécessaire de le préciser...

:fumer:
votre avatar
Surrout que ce sont des repos privés de ce que je comprends. Je peux pas partager ceux de ma boîte pourtant c'est ceux là qui sont alimentés. Le mien perso ne bouge plus depuis quelques temps maintenant.
Et je suis pas ingé soft.
votre avatar
Un ingénieur logiciel n'est pas un coder.
En tout cas, ce mec ne redore pas le blason des développeurs PHP.
votre avatar
mouais bof, moi j'suis payé au nombre de lignes dans mon code :fume:
votre avatar
Commentaires inclus ? :D
votre avatar
Faut remplacer les boucles par du code répété alors. Avec une petite boucle dans l'éditeur pour le genérer bien sûr
votre avatar
ensuite je passe le tout dans un offuscateur et je garde l'original sur mon ordinateur perso. ca ajoute des lignes et me rend indispensable :8 n'hésitez pas à me contacter si vous avez des projets :)

qualité et prix bas ! pour le BF, 3 lignes achetées 2 lignes payées
votre avatar
i =
i +
1;

?
votre avatar
Mais ce n'est pas forcément de leur faute. Si on ne leur demande rien logique qu'ils ne fassent rien.
votre avatar
Viiite, remplaçons tous les devs par des IA qui pondront 10x plus de code tous les jours. Merci Yegor pour toutes ces belles économies à venir.
Moi ce qui m'intéresserait, c'est de savoir à quel prix il veut vendre ses analyses nocives.
votre avatar
Ah, l'éternelle tentation du flicage !
Le retour de la pointeuse !

Je vous offre un petit exemple, qui va vous apparaitre classique, concernant du support par tickets :
Si on considère qu'un meilleur technicien qu'un autre traite plus de tickets qu'un autre, eh bien vous aurez des baudruches (ie pleines d'air) qui vont créer/clore du ticket en masse :
* Pas répondu ? Clos
* Répondre et clore même si le problème n'est pas réglé : si le client répond cela ouvrira un autre ticket

Aujourd'hui, les services de supports, quand ils existent encore, sont soit sans humains, soit embauche des humains les moins payés possibles, donc les moins compétents possibles, à qui il faut répéter en boucle les mêmes questions pendant des semaines sans qu'aucune réponse ne soit apportée.
À leurs messages d'une ligne, il faut répondre en détails et tester de son côté : il ne font rien, produisent rien, ne testent rien eux-même.

Ce monde du support est l'évolution naturelle d'une approche quantitative.
En définitive, l'approche quantitative (la seule mesurable, parce que la qualitative… bon courage pour ne pas obtenir une usine à gaz arbitraire & injuste) amène simplement à un renforcement des baudruches.

Définir un "bon" ingénieur par un volume de commits, c'est la même chose.
Sombre idée, et vous allez vénérer des robots-baudruches en aliénant d'autres, dont le travail ne se translate pas directement en commit.

Décidément, la tentation fasciste n'est jamais loin dans les modèles autoritaires/arbitraires qui forment le monde l'entreprise d'une certaine idéologie.
votre avatar
Et ce genre "d'étude" va être la source utilisée pour virer ~10% des employés. Sauf que le pourcentage d'ingés ne foutant rien sera toujours le même après.

Parce que même si on oubli la méthodo pourrie, les ingés n'ont pas de "productivité" fixe. Il suffit qu'un môme soit malade, puis refile la maladie à l'autre môme, pour que tu passes un mois sans dormir correctement, et avec une productivité quasi nulle, ce qui ne veut pas dire que t'es un mauvais ingé.

Mettre des métriques sur l'humain ne fonctionne simplement pas.
votre avatar
Il y a tellement de truc qui vont pas dans cette analyse que j'avoue avoir un peu de mal à comprendre qu'elle soit relayé (no offense).

Pour l'exercice rapide, si j'en crois wikipedia: "Un ingénieur logiciel est une personne qui applique les principes du génie logiciel pour analyser, concevoir, développer, tester, évaluer et maintenir des logiciels." ici le monsieur n'évalue que la partie développer (sic) et même ça il le fait très mal (sic bis).

- Est-ce qu'un senior doit produire beaucoup de commit ou faire d'avantage du peer review pour améliorer le code des junior? est-ce que le rôle d'un lead est de produire du code en masse? (bref, un métier, plusieurs séniorité et rôle ...)
- Sinon, comment évaluer les utilisations pas optimum de git (rebase en local pour commit en une fois une feature plutôt que de passer par une branches, coder en local et push une fois à autre pcq on comprends pas git, les bypass pour fixer rapidement en prod le vendredi soir ce qui ressort pas dans l'historique ...)
- BTW, ça doit faire 25 ans que la LoC est considérée comme mauvaise KPI pour évaluer une productivité ... (pas plus tard que début du mois, une news est passé sur intel qui améliore de 3500% les performances en modifiant une seule ligne de code ...)
- Bref, c'est sans fin (et on parle même pas du contexte externe, des réunionites aigu et autre facteur externe pourrissant le job).


En vrai, avec une pointe défaitisme et de sarcasme, ça donne juste envie de créer une startup future licorne IA based mon cul sur la commode qui améliore la productivité des ingénieurs logiciels et de lever des millions d'euro avec pour toute technologie un git hook qui split les commits en plusieurs commit ou qui en ajoute d'autre avec du vent (fichier vide, commentaire inutile, voir qui crée des fix en retirant des fichiers vide crée par des commits précédant ...).

Sick sad world !

PS: du reste, ça retire rien au fait qu'il y a sans doute bien 10% d'ingé logiciel qui en glande pas une (pour de bonne ou de mauvaise raison, mais ça change rien au fond du sujet ...)
votre avatar
Avec de l'IA tu dois pouvoir faire mieux. Introduction automatisée de bugs, puis correction dans d'autres commits un peu plus tard.
votre avatar
clairement, mais il y a un impact sur la production. je suis sur que faire juste du vent sans impact paye quasiment aussi bien :)
votre avatar
Pas forcément d'impact, faut s'assurer que le bug ne soit pas déployé.

Bon, qui ça te gêne si j'utilise ton idée ? Qui veut s'associer pour monter un business.

WindCode. Develop faster, for the cloud. (*)

* Faster. Not better. Not even useful. Just more code.
votre avatar
Effectivement la conception ne fait pas bouger le clavier hein. Et c'est bien souvent (quand c'est bien fait) un truc qui ne fait pas de commit et qui consomme plus de temps que le développement.

La question la plus importante, au-delà de la méthodologie, c'est : Qui a commandé l'étude ?

De nos jours (et surtout malheureusement) la science est très prompte à souffler dans le sens du chéquier.
votre avatar
Et plus la conception est bien faite en amont moins tu as de changements et donc de commits. Oups ?
votre avatar
dev ≠ pisse-code
mais bon, c'est pas comme si sa "méthode" avait été débunkée y'a plus de 30 ans, hein...
https://folklore.org/Negative_2000_Lines_Of_Code.html
votre avatar
L'évaluation par le nombre de commits a t'il un lien dans la démarche avec le hindex ?
votre avatar
C'est génial, on se rend compte (certains depuis un moment, d'autres qui commencent à se réveiller) que le volume de production scientifique est un indicateur à la zouave, et des gloglos se mettent à imaginer pareil sur le nombre de lignes de code (ce qui est encore pire, car on peut commiter beaucoup en passant son temps à réparer des erreurs dues à la production hâtive de code). J'ai l'impression que la notion de RETEX (déjà appliquée souvent d'une façon assez risible dans les administrations et les entreprises) est clairement absente (on peut analyser ce que font les autres et en bénéficier).
votre avatar
Commit or not commit. That is the question :fumer:
votre avatar
Quand je vois le nombre de commentaires sur Next, doit y avoir effectivement une bonne part de fantômes dans l'informatique :francais:

Et quand je m'aperçois que j'en écris aussi, ça ne doit pas être réservé au secteur 😜

Sans même parler de tous les parasites d'actionnaires qui s'enrichissent sur le labeur des travailleurs, Une vision très étriqué du monde du travail cette "étude", mais au moins ça fait gratter un paquet de monde 😁
votre avatar
J'imagine toute l'équipe du gars bosser 2-3 mois pour forcer à collecter des données de git ici et là pour sortir 2-3 graphes derrière. Tout ça pour dire que d'autres ne travaillent pas. C'est d'un niveau ^^
votre avatar
Mince, et les 10% qui codent en prod sont ignorés!
votre avatar
Je travaille en milieu normé (Aero) et on fait plus de paperasse/fustification que de code.
Plus de la moitié des personnes ayant accès au repo ne font pas de code (manager, qualité, testeur). La méthodologie me parait un peu foireuse.
votre avatar
La méthodo est foireuse pour sortir des stats mais la conclusion est assez raisonnable. Pour bosser dans une boite pas si mal gérée, on voit énormément de personnes avoir un impact nul voir négatif, elles tiennent des mois ou années avant de se faire débusquer (si ça arrive), la faute a des managers eux même absents/nuls/inutiles.

Tout le monde acquiesce quand on parle de bullshit job mais si on pointe les ingés, ça se peut pas car on est on magiquement épargnés :top:
votre avatar
on voit énormément de personnes avoir un impact nul voir négatif,
Ou du moins, c'est ce qu'on croit. Je pense qu'on est tous le branleur d'un autre et qu'il est malvenu de balancer des jugements à l'emporte pièce sur les collègues.
votre avatar
C'est assez optimiste sur le monde de dire qu'on contribue tous positivement (dans des boites elles aussi très gentilles et positives). Je n'ai rien lancé à l'emporte pièce, je peux te raconter en détail ce dev qui s'estime très senior mais n'arrive pas à passer le test technique qu'on donne aux stagiaires... ou encore le manager absent qui fait la semaine de 4h.

Le relativisme ne permet pas de piloter une entreprise, si tu veux compenser justement ceux qui s'impliquent il faut savoir discriminer sur l'impact (ce qui est un sujet difficile)
votre avatar
Ce sont des cas à la marge. Ça existe, mais ça ne justifie pas d'en faire des caisses. Je veux bien voir l'état des boîtes qui se mettraient à licencier 10% de leurs développeurs, sur la base de critères quantitatifs (ou plaintes des collègues qui pensent qu'ils valent mieux).
votre avatar
Peut-être un adepte de Musk qui savonne la planche de l’efficacité pour bien dégraisser. alors la méthode… Mais il faut reconnaître que c’est sophistiqué.
votre avatar
Se baser sur les commits c'est juste ridicule et je ne citerai qu'une seule chose qui plombe déjà cette métrique : peer programming.
votre avatar
Quantité de travaille nombre de commits sur GIT ?
Mais quelle réflexion stupide montrant la totale méconnaissance du métier d'ingénieur !

Premièrement un ingénieur logiciel n'est pas un pisseur de code !
C'est avant tout du du conseil : comprendre le besoin, chercher les différentes façon d'y répondre, et identifier la bonne selon différents critères (la réponse au besoin, le coût, la maintenabilité, la sécurité, les perf...).
Le bon conseil est parfois... de ne pas faire de code. Les plus mauvais dev' sont ceux qui écoutent à moitié le besoin et courent coder et tordre leur logiciel / framework qu'ils connaissent, coûte que côute pour répondre au besoin.
L'ingénieur logiciel a également d'autres casquettes : il pond des specs, des tests, des docs de formations utilisateurs, anime des ateliers UX, organise la formation technique de ses collègues...

En admettant, qu'on ne souhaiterait que mesurer la capacité à pisser du code, le nombre de commit n'est pas un bon indicateur :
Comment est considéré un commit un peu gros contenant une grosse feature, et n'ayant généré aucune régression ? à l'inverse un dev qui commit à tout-va ne teste jamais rien et génère 4 - 5 régressions à chaque fois qu'il touche du code, serait bien vu car il aurait beaucoup de commit à son actif ?

Selon une étude, près de 10 % des ingénieurs logiciels « ne font pratiquement rien »

Fermer