Les révisions de code sont-elles nécessaires pour les développeurs débutants?


39

J'ai travaillé pour deux sociétés, chacune ayant une méthodologie différente en matière de révision de code:

Dans la première entreprise, les chefs d’équipe ont procédé à une révision du code et l’ont exigé à la fin de chaque module.

Toutefois, dans la deuxième société, les chefs d'équipe n'étaient pas tenus de réviser le code et venaient de vérifier les problèmes de fonctionnalité et de conception.

Donc je suis confus. Le processus de révision du code est-il vraiment nécessaire? Si c'est le cas, pourquoi? Et si ce n'est pas le cas, pourquoi pas?


28
Si les développeurs

2
@Tilsan The Fighter: C'est bien que vous posiez des questions - curieux est, ou devrait être, un exploit de programmeur - mais veuillez les rendre compréhensibles et faciles à lire.
Gablin

9
@Thorbjorn - Ce n'est vrai que si les développeurs seniors sont seniors en raison de leurs compétences et non de leur durée. J'ai vu beaucoup de mauvais code et de mauvais designs d'ingénieurs seniors
KallDrexx le

8
Il peut y avoir une bonne raison, et il est bon de découvrir cette raison, mais vous ne devriez pas faire aveuglément confiance à leurs conseils en raison de leur titre et de leur expérience de X années. J'ai demandé à l'ingénieur principal ici pourquoi il avait créé beaucoup de mauvais code et tout ce que j'ai obtenu est un haussement d'épaules avec un "Je ne sais pas". Il y a suffisamment de mauvais ingénieurs pour me faire réaliser que je ne fais pas confiance à un titre seulement.
KallDrexx

4
+1 KallDrexx - c'est ce que j'ai trouvé aussi. J'ai souvent eu un développeur "senior" qui ne savait pas pourquoi il ne fallait pas tout coller dans une classe statique, ni savoir quoi que ce soit à propos des tests, ni connaître les modèles de conception appropriés. "Senior" se réfère généralement à la tenure et non aux compétences. ce que je peux dire
Wayne Molina

Réponses:


107

Personnellement, je pense que chaque élément de code doit faire l’objet d’une révision, peu importe que vous soyez développeur junior ou senior.

Pourquoi? Pour commencer, votre titre ne dit rien sur votre développement, et un développeur senior pourrait apprendre quelque chose du junior. Dans notre entreprise, nous nous déplaçons de manière à ce que l'un des autres membres de l'équipe vérifie votre code ... la plupart du temps, nous sommes associés à un "junior" et à un senior, de sorte que tout ce qui n'est pas dit quotidiennement ne peut être pris dans un suivi. Si l'aîné n'aime pas le code junior, il devrait écouter pourquoi il a agi comme il l'a fait et le regarder pour voir si c'est une solution réalisable qui pourrait être utilisée à l'avenir ... il s'agit simplement de devenir plus sage, peu importe. qui tu es.

Une chose importante à propos de la révision du code est que vous n'êtes pas trop gentil. Si vous êtes un bon gars, vous autoriserez simplement un code de plus en plus désordonné à évoluer dans le système. Comme hier, j'ai commencé à retravailler une application complète écrite par un ancien développeur juniord, et mon dieu, ce code aurait pu nécessiter une révision avant son départ.

Je ne vois pas pourquoi ce devrait être le chef d'équipe qui se contente de faire des critiques, mais cela nécessite une personne qui n'a pas peur de se battre pour un code mal développé, et qui doit se soucier de la façon dont le code devrait être utilisé. être. Toutes les entreprises n’engagent pas des personnes qui s’intéressent réellement à ce qu’elles font, et ces mauvais œufs ne devraient pas permettre à l’OMI de procéder à la révision du code, car ils sont susceptibles de hausser les épaules et de dire «OK» au mauvais code.


8
En fait, il est utile que le chef d’équipe procède à la révision du code. Même un développeur moins expérimenté devrait pouvoir suivre le code. :)
Guffa

63
Le code des chefs d'équipe doit également être revu, car les développeurs débutants peuvent souvent apprendre des techniques utiles ou au moins voir à quoi un "bon" code est censé ressembler. Et ce n’est pas parce que vous êtes chef d’équipe que vous ne pouvez pas vous tromper.
TMN

4
@TMN, je ne peux pas être plus d'accord. Les chefs d'équipe ne sont pas toujours choisis en raison de leurs compétences ou de leur expérience. parfois ce sont tout ce qui reste après un exode massif (ce qui est arrivé plusieurs fois où je travaille), ou un grand licenciement. Le code de tout le monde devrait être révisé, quels que soient l'expérience, le statut ou le titre.
bedwyr

2
@TMN Trop bien. Le titre "développeur senior" ne signifie pas "incapable de faire des erreurs" ou "incapable de progresser". Si tel est le cas, ce n'est pas le type de développeur principal que je souhaite dans mon équipe.
Brandon DuRette

2
Je suis très expérimenté et bon dans ce que je fais. Je commets des erreurs, dont beaucoup ont été détectées lors de la révision du code.
David Thornley

37

Fondamentalement, la révision de code est nécessaire pour tous les programmeurs, quelle que soit leur expérience. C’est le contrôle de la qualité du développement logiciel, et l’une des raisons pour lesquelles l’Open Source peut être de très haute qualité.

EDIT: La raison en est qu’un réviseur de code a aujourd’hui exactement le même rôle qu’un responsable. Si le code n’a pas de sens pour lui aujourd’hui, cela ne le sera pas plus tard, ce qui rendra les bugs plus coûteux à réparer. Par conséquent, rendez-le compréhensible aujourd'hui alors que le développeur se souvient encore du code. De plus, le relecteur peut voir des bogues ou des omissions manquées par le développeur.

Malheureusement, très peu d’entre eux souhaitent le faire, mais d’un point de vue commercial, cela devrait être obligatoire.


@ Mr.Thorbjorn Ravn Andersen: Pouvez-vous préciser quels sont les avantages et les inconvénients du processus de révision du code?
Sankar Ganesh

2
cette proposition de révision de code pourrait vous intéresser . Ce serait bien si nous pouvions lancer le processus.
Grand

@Victor, une approche intéressante et je vous souhaite bonne chance.

@Sankar Ganesh: il y a un livre gratuit sur l' examen du code qui traite des avantages et des inconvénients: smartbear.com/best-kept-secrets-of-peer-code-review
Joeri Sebrechts

17

Je travaille dans un endroit où la révision du code est maintenant une exigence mais n'était pas aussi petite qu'il y a trois ans. Cela a considérablement amélioré notre code et la capacité des autres utilisateurs de le conserver plus tard. Même les développeurs expérimentés et chevronnés commettent des erreurs qui peuvent être corrigées facilement et silencieusement lors de la révision du code avant que le contrôle qualité ne les détecte, ou pire encore, avant que le client ne les détecte. De plus, au moins une personne autre que le développeur d'origine connaît le code.

Souvent, lorsqu'une organisation essaie quelque chose de nouveau, comme nous l'avons fait avec la révision de code, il y a beaucoup de résistance au changement. J'ai vu à peu près rien de tout cela (nous étions également prêts à obtenir un service formel d'assurance qualité.) Avec la révision du code. Il suffit d’une ou deux revues pour voir le rapport qualité / prix.

J'ai découvert de nouvelles techniques que je n'avais pas prises en compte lors de la révision du code du travail de quelqu'un d'autre ou de la révision de mon code. Nous avons trouvé assez rapidement des problèmes de compétence chez les nouveaux employés en procédant à la révision du code et, plus important encore, à la manière dont ils ont répondu à la révision. Nous avons appris ce qui semble parfaitement clair en ce moment même au cœur de la programmation de cette section qui ne sera pas clair en maintenance. C'est inestimable. Peut-être que la seule chose nécessaire est un commentaire expliquant pourquoi quelque chose a été fait. Nous avons constaté que certains malentendus fondamentaux au sujet de la conception de notre base de données devaient être corrigés pour qu'un rapport contienne les informations correctes.

Souvent, ce que j'ai vu dans une révision de code, c'est que, par le simple fait d'expliquer quelque chose à quelqu'un, le développeur se met à allumer une ampoule et se rend compte qu'il existe un bug que le réviseur n'a pas vu.

Et garçon peut revoir le code pour identifier les programmeurs cow-boys qui ne suivront aucune norme ni n’utiliseront d’outils obligatoires et dont le code ne sera pratiquement pas maintenable par quiconque. Et cela peut les forcer à suivre le programme ou à en sortir aussi.

Les personnes les plus réticentes à la révision de code sont souvent les personnes dont l'organisation a le plus besoin de se débarrasser, car elles savent que leur code ne peut pas passer une révision de code.


3
"Nous avons constaté assez rapidement des problèmes de compétence chez les nouveaux employés en procédant à des révisions de code et, plus important encore, à la manière dont ils ont réagi à cet examen" - Il s'agit d'un avantage très important (et je suis d'accord pour dire que leur réponse en dit plus que leurs erreurs) .
Stephen C. Steel

1
+1 pour capturer les pourquoi

11

Un gars agile dirait: "Vous n'avez pas besoin d'une révision de code, faites juste de la programmation en binôme et écrivez de bons tests" :)


9
Et changez de paire souvent et reconnaissez que ce sont les codes qui appartiennent à l’équipe, et non à un individu.
Don Roby

18
Le gars agile a tort. Le code doit être revu par un esprit indépendant de l’esprit qui l’a créé. (Il est très facile pour une paire de programmeurs de se parler sans le savoir!)
Peter Boughton

6
La programmation par paires est une révision de code continue.

3
@Peter: Agile guy ré-associe également à distance et pratique la propriété de code commun. Ainsi, sur une période de temps (quelques jours à plusieurs semaines), la plupart des autres membres de l'équipe ont examiné le code écrit par la paire d'origine. Le gars agile a une réponse à tout. Certaines personnes pensent que le gars agile est une smartass totale .
Tom Anderson

2
La programmation par paires corrige le problème principal des révisions de code: elles se produisent beaucoup trop tard. Je déteste aller à la révision du code pour voir que le développeur a passé une semaine à réaménager un algorithme de bibliothèque ou une structure de données.
kevin cline

8

La révision du code est un bon moyen de diffuser les connaissances et les bonnes pratiques au sein d’une équipe. D'après mon expérience, c'est une bonne idée de s'assurer que tout le code est examiné et d'essayer de faire varier le code de chaque critique.

Dans mon équipe actuelle, le code de Everyones est revu de manière égale, et le programmeur et le relecteur doivent être satisfaits du code avant de pouvoir le publier. Cela vaut tout autant pour les développeurs seniors examinés par des développeurs plus juniors, par un développeur junior en évaluant un autre ou par d'autres développeurs expérimentés en train de se réviser. Si le réviseur est inexpérimenté ou ne se sent pas à l'aise pour réviser un élément de code particulier, il fera équipe avec un autre développeur (et peut-être aussi le développeur d'origine) pour effectuer la révision en tant que groupe.


2
Oui, l'examen de code est autant un contrôle de qualité qu'un partage de connaissances. Tout le monde peut apprendre d'une bonne revue de code. Le reviwer et le critique.
Guillaume

1
Mon entreprise est semblable à celle de flamingpenguin. Chaque enregistrement est examiné par un autre développeur. Rank n'a rien à voir avec qui passe en revue quoi. C'est un processus peer-to-peer. La condition est que tout le code soit revu. Les révisions de code de style parent-enfant ne servent qu'à chasser les développeurs "A", laissant à un responsable d'équipe "B" la révision des juniors "C". Le meilleur code qu'une équipe de style parent-enfant peut espérer est un code médiocre. S'ils ont de la chance.
Jim In Texas

5

Je travaille dans ce secteur depuis plus de 20 ans, travaillant pour des éditeurs de logiciels et pour différentes entreprises et aucun de ces endroits n’avait un processus de révision de code. Cependant, je peux comprendre et apprécier les avantages d’en avoir un. D'après ce que je comprends, ils devraient essentiellement être utilisés pour garantir le respect des normes, qui devraient être suivies afin que d'autres puissent gérer plus facilement le code à l'avenir. La lisibilité du code peut également être vérifiée dans un processus de révision, car cela garantira également que la maintenance peut fonctionner efficacement avec le code.

Actuellement, je travaille dans un petit magasin où je suis le développeur unique. Nous avons parfois fait appel à des entrepreneurs pour nous aider à traiter les arriérés. Au moins un ou deux de ces contractants ont rédigé un code qui ne respectait pas nécessairement les normes de la mienne ou de la société, mais il fonctionnait bien et était au moins assez compréhensible. Lorsque j'ai signalé ce problème à la direction, ils s'en moquaient, ils voulaient simplement savoir si cela leur rapportait ce que nous leur payions. Donc, je suppose que cela dépend de la société et de la question de savoir si le code souhaité est propre, facile à gérer, ou s’ils veulent simplement quelque chose qui fonctionne bien pour leur argent.

Évidemment, en tant que développeur, et qui doit maintenir le code, j'aimerais travailler avec du code propre qui respecte une norme quelconque, mais je n'ai pas toujours ce luxe, alors je tire le meilleur parti de ce que j'ai et traite ce que j'ai. , même si cela implique parfois de réécrire du code dans mes propres standards.


4

Les révisions de code peuvent identifier les défauts plus tôt dans le cycle de vie du logiciel lorsque les problèmes sont plus faciles (et moins coûteux) à résoudre. Chez SmartBear, nous avons développé un outil de révision de code par des pairs et avons également mené de nombreuses recherches sur la manière de rendre les révisions de code efficaces. Selon les données de nos clients, les défauts détectés lors de la révision du code coûtent 8-12 fois moins cher à trouver et à corriger que ceux détectés dans le contrôle qualité. Les économies de coûts à elles seules font que la révision de code en vaut la peine, mais il y a plus de valeur que cela. La révision du code est un excellent moyen pour tous les membres de l'équipe d'apprendre et de s'améliorer en tant que développeurs de logiciels.

Certains pièges peuvent rendre les révisions de code moins efficaces, et il semble que votre organisation soit prise dans l'un d'entre eux. Faites la révision du code sur le code, pas les personnes. Les titres ne signifient rien dans une révision de code. Les appels à l'autorité (vous devez le faire à ma façon parce que je suis le chef d'équipe) font plus de mal que de bien. Enseigner à la place. Les ingénieurs en chef devraient expliquer pourquoi cela devrait être fait comme ils le souhaitent et pas seulement l'exiger. Si vous avez du mal à expliquer un concept, vous vivrez également une expérience d'apprentissage. Vous serez tous deux de meilleurs développeurs pour les efforts que vous déployez.


Avez-vous un article officiel traitant des 8-12 fois moins cher? Nous en discutons en interne.

@ Thorbjørn - Nous le faisons: goo.gl/7dMf . Cela provient de notre livre sur la révision du code, que vous (et n'importe qui d'autre) pouvez avoir gratuitement: codereviewbook.com
Brandon DuRette

2

Je pense que la révision de code par ALL CODE est excessive. Le temps nécessaire pour examiner tout le code pourrait être mieux dépensé ailleurs. Alterntivley, je pense que le code critique et / ou les éléments particulièrement complexes nécessitent une révision du code, mais certainement pas toutes les lignes de code.


7
Je ne pouvais pas être plus en désaccord. Chaque ligne de code doit faire l'objet d' au moins deux révisions ... le développeur d'origine doit absolument contrôler chaque modification de ligne avant de les valider, et au moins un autre développeur doit effectuer une révision par les pairs pour assurer le suivi. Très rarement, le code passe à travers une révision sans au moins une bonne question posée; Les examens par les pairs permettent également aux membres de l’équipe de mieux comprendre ce que les autres personnes accomplissent et comment.
STW

3
@Gratzy - Je ne jure que par cela; normalement, il ajoute ~ 10% au cycle de développement; un petit investissement pour combien nous attrapons tôt.
STW

4
@Gratzy - tout simplement parce que nous ne sommes pas parfaits. Notre équipe a considérablement grandi et nous avons un certain roulement (principalement des sous-traitants). Dans le passé, lorsque nous nous sommes retirés de l'examen, des problèmes de politique générale se sont posés presque immédiatement. Le processus de révision est simplement une étape critique dans le maintien d’une équipe efficace et dans la production d’un produit de qualité. Réviser tout le code n'est pas difficile. surtout si vous avez un couple de développeurs expérimentés qui sont très doués pour trouver du code vierge. La plupart du code en double provient de développeurs qui réussissent bien, mais ne sont tout simplement pas au courant d'une approche existante.
STW

5
Je suis avec STW à ce sujet - résoudre les problèmes résolus lors de la révision est beaucoup moins cher que d'essayer de déboguer / maintenir le code plus tard, car il n'était pas considéré comme critique. En outre, les critiques de code ne prennent du temps que si le code est mauvais - un bon code est rapide et facile à lire!
Peter Boughton

7
Bien sûr, ils ne devraient pas, mais cela ne signifie pas qu'ils ne le sont pas! (Combien d'équipes ont des développeurs parfaits?) Quelles lignes de code ne passez-vous pas en revue? Comment décidez-vous si un changement particulier dans un fichier particulier doit être examiné ou non?
Peter Boughton

2

À mon avis, le code utilisé par une entreprise, qu’il ait été écrit par un développeur junior ou senior, devrait toujours être révisé. Pourquoi? Parce que si le code avait plusieurs bugs? Et si, pendant l'utilisation de ce code, le programme se bloquait? Pour éviter que cela ne se produise, tout le code doit être examiné avant utilisation.

Mais qu'en est-il des entreprises qui ne révisent pas le code? Ce sont probablement les entreprises qui ont beaucoup de problèmes techniques et qui, comme ils disent aux consommateurs, sont des "pannes" ;-).

Alors laissez-moi répondre à toutes vos questions:

  • Oui, le processus de révision est nécessaire.
  • Pourquoi? Pour les raisons que j'ai mentionnées ci-dessus.

2

Examen du code : le processus d’examen du code doit être vital pour tous. Je vais expliquer qui bénéficie de tous les avantages découlant de l’examen du code et des avantages qui en découlent.

1. Avantages obtenus par la société en raison de la révision du code: Si la révision du code est fréquente, la société peut obtenir les produits finaux de manière bien plus optimisée, ce qui les aide à obtenir la marque sur leur marché et à aider la société à obtenir ou améliorer leur niveau CMMI actuel .

2. Avantages pour le chef d’équipe grâce à la révision du code: Comme nous le savons tous, un enseignant peut facilement identifier les erreurs, car il examine les réponses de ses élèves plus fréquemment, afin de leur donner une idée des domaines dans lesquels être possible pour les mauvaises choses. De même, le chef d'équipe sait également ce qui ne va pas dans ce domaine. Comment pouvons-nous les rectifier? Et aider également le chef d’équipe à saisir également les nouvelles idées du développeur débutant.

3. Avantages pour le développeur débutant en raison de la révision du code: le développeur débutant peut facilement saisir les idées sur le processus de révision du code, mais il est également en mesure d’obtenir ce qu’est la norme de codage, Par exemple: pour créer une API de manière appropriée, ils apprendront la normalisation du codage qui pourrait les aider à l'avenir, en particulier lorsqu'ils occuperont un poste de niveau supérieur.

Donc, ma conclusion est que l'examen du code est un processus très essentiel pour tous [même pour les membres de l'équipe], car l'examen de code nous aide à corriger les erreurs d'inattention de notre code, car nous sommes tous des êtres humains, nous ne pouvons donc pas prédire que nous ne le ferons jamais. faire des erreurs d'inattention dans le code.


1

Quelle est la différence entre interférer dans vos idées avant de vérifier votre code (révision) ou après en raison d'un bogue, devenir trop intelligent / difficile à comprendre, ou ne pas suivre les pratiques standard acceptées? Est-ce votre ego?

Vous ne pouvez pas négliger les mérites de la révision de code ou quoi que ce soit d'autre simplement parce que la mise en œuvre est médiocre par un membre de l'équipe moins qualifié que vous ne respectez pas. La révision de code n'est pas un processus très complexe que seuls quelques super programmeurs sont capables de comprendre. Je ne suis pas sûr qu'il y ait beaucoup de programmeurs ou de rédacteurs professionnels capables ou ayant le temps de s'auto-éditer.

Êtes-vous déjà retourné à une ligne de code quelques mois plus tard et vous demandiez à quoi je pensais? Il y aurait une meilleure chance de le rattraper avec une révision du code. Vous venez de l'attraper et vous n'êtes que légèrement meilleur que le programmeur que vous étiez il y a quelque temps - j'espère.


1

Une révision du code de l'OMI devrait être essentielle pour tous les développeurs, mais uniquement lorsque les personnes chargées de la révision sont compétentes. Dans le passé, un code avait été rejeté dans une critique parce que, je vous ai mal SOLIDcompris , j'ai suivi , effectué une injection de dépendance et organisé le code en espaces de noms et dossiers, conformément à la conception logique, et comprenant une petite suite de tests unitaires. vérifier le code. Le code a été rejeté comme "trop ​​compliqué" et on m'a dit d'utiliser une classe qui scelle tout et supprime les tests, car ce n'est pas ainsi que l'entreprise a écrit le code.

Une telle révision de code n'a aucune valeur, mais une révision de code avec une équipe compétente peut souvent éclairer la conception (par exemple, pourquoi choisir X et Y mais pas Z) ou indiquer une faille réelle (par exemple, faire X entraînera l'échec de Y pour des raisons incorrectes).


1

Bien sûr, la révision de code n'est pas nécessaire . Là encore, ni les tests, ni l’intégration continue, ni le contrôle de source, ni la participation des clients, ni le profilage, ni l’analyse statique, ni le matériel approprié, les constructions en un clic, le suivi des bogues, etc.

Parallèlement à la révision du code, les éléments mentionnés ci-dessus sont des outils permettant de garantir la qualité des logiciels. Avec une combinaison d'adresse, de chance, de temps et de détermination; vous pouvez fournir un logiciel de qualité sans rien de tout cela, mais il est plus probable que vous ne le ferez pas .

Dans votre scénario, il n'y a rien à confondre. Toutes les organisations ne se plient pas à toutes les meilleures pratiques. Ils peuvent être en désaccord avec cela, cela peut entrer en conflit avec une meilleure pratique différente qu'ils mettent en œuvre, ou ils peuvent considérer que les frais généraux liés à la mise en œuvre sont trop importants pour eux à ce stade. Selon leur situation, ils peuvent avoir raison de le faire ou bien, ils peuvent créer une fausse économie. Pour certains outils (contrôle de source, par exemple), le rapport coût / effort est si bon que son utilisation est une évidence. pour d'autres c'est moins clair.

Il ne fait aucun doute que la révision de code est une pratique qui entraîne des frais généraux importants. Pour cette raison, les organisations chercheront à minimiser ces frais généraux, soit en ne le faisant pas du tout, soit en ne le faisant que dans certaines situations (par exemple, pour un membre de l'équipe junior ou pour un changement particulièrement difficile). Il n’est pas toujours évident que cela rapporte plus que cela coûte (attraper des bugs, réduire la dette technique ou partager les connaissances). La plupart de ces retombées sont difficiles à quantifier, alors qu'il est très facile de compter le nombre d'heures-homme que votre organisation consacre à la révision. Le bit le plus facile à quantifier (nombre de bogues réduit) est facile à attribuer à d'autres facteurs (par exemple, "bien sûr, il y a moins de bogues, il est plus mature").


-1

Nous faisons du football en ligne en Turquie. Beaucoup d'utilisateurs et de maîtres de jeux nous aident sur les fonctionnalités. En outre, ils donnent des commentaires sur les fonctionnalités nécessaires. Je pense donc que, si vous avez beaucoup d'utilisateurs, des tests de fonctionnalité peuvent être effectués pour aider ou obtenir des badges. La collaboration de développeurs, de maîtres de jeux et d’utilisateurs avec des forums, des équipes de support et des environnements de test privés crée un projet social.

Des révisions de code sûres et le partage d'expériences entre les équipes de développement sont nécessaires, mais si ce n'est pas critique, vous n'avez pas à vous forcer.


-1

Je pense que l'inspection verbeuse de deuxième partie dépend de votre cycle de vie, que vous soyez plus agile ou de plus en plus de cascades dans vos processus. Je pense qu'il est raisonnable de faire des conceptions / inspections de haut niveau, ainsi que des inspections de conception plus détaillées. Je pense qu'il est également bon d'impliquer plusieurs membres d'une équipe à inspecter.


-1

Ils sont absolument nécessaires car ils ont peu d'expérience.


sans une explication, cette réponse peut devenir inutile dans le cas où quelqu'un d'autre affiche une opinion contraire. Par exemple, si quelqu'un publie une réclamation du type "Ils ne sont absolument pas nécessaires car ils ont peu d'expérience", en quoi cette réponse aiderait-elle le lecteur à choisir deux opinions opposées? Envisagez de le modifier pour le transformer en forme
gnat
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.