Avant propos:
Je comptais en faire un commentaire LinkedIn, puis un post sur ledit site. La limitation en nombre de caractère fait que ce sera un journal ici, même si le public de LinuxFR n'apprendra sans doute pas grand chose.
Je viens de lire un conseil aux débutants en développement informatique, pour "booster" son CV et trouver un premier boulot.
"développe ton propre site", un clone de stackoverflow, de youtube, etc.
Alors bien sûr, cela a des vertus éducatives, ce sont les fameux travaux pratiques. Cependant, cela peut représenter une somme de travail non négligeable, à devoir faire du full-stack, du design, du graphisme… Et ce, même si une partie seulement de ce travail est celle que vous voulez mettre en avant pour une candidature.
Un autre problème est que le résultat sera possiblement:
- soit minimaliste et pas très attrayant (au risque de vous desservir)
- soit un gouffre de votre temps libre (ce temps à consacrer à votre recherche d'emploi).
Vous vous êtes vraiment investie et avez décroché un job grâce à votre super site "vitrine" sur lequel vous avez passé tant d'heures, félicitations ! Il va à présent pouvoir mourir. Ah, zut.
Mon conseil : ne réinventez pas la roue carré, et contribuez à un projet de Logiciel Libre.
Trouvez un projet existant, qui vous plait, avec de vraies problématiques (de refonte, de performances, d'architecture, ou tout simplement de main d'œuvre et de temps). Idéalement un projet avec une équipe : la collaboration est une qualité importante en développement. Personne n'a envie de bosser avec la personne qui sait coder dans son coin mais qu'on n'arrive pas à relire.
On devient aussi tout simplement meilleur développeur en lisant du code écrit par d'autres. Parfois c'est pour se dire "ce truc est super bien écrit !", parfois pour se dire "je ne suis pas si mauvaise après tout". Ne pas négliger ce point, toujours bon pour lutter contre ce fameux syndrome de l'imposteur.
Si vous n'avez plus de temps à consacrer à ce projet, votre code continuera de vivre. Un peu de temps libre irrégulièrement ? Parcourez la liste de bugs de votre projet (ou d'autres) et soumettez quelques correctifs. Et si le temps et l'envie sont toujours là, vous avec sous les yeux une bonne source d'expérience.
En retour, vous vous créerez une e-réputation, utile pour vos emplois futur. En entreprise, vous n'aurez pas forcément l'occasion de contribuer à du code visible par tous. Vous changerez un jour d'employeur, et il ne pourra pas lire ce code propriétaire que vous dites avoir écrit. Mais contribuer à un projet Libre laisse une empreinte, et des sites comme https://www.openhub.net/ par exemple vous permettront d'avoir une trace centralisée de vos contributions.
Vous avez une super idée de projet à monter qui vous motive ? Foncez ! Mais n'oubliez pas que ce n'est ni le seul chemin, ni le plus simple. Car si au final vous n'arrivez pas à le finir pour des raisons diverses (perte d'intérêt, blocage technique), vous n'aurez rien à montrer à un potentiel employeur, et aurez gaspillé du temps. Les projets informatiques qui échouent, ce n'est pas ce qui manque… Certes vous aurez certes acquis de l'expérience, mais celle ci sera difficilement démontrable, et vous aviez commencé ce projet pour justement avoir quelque chose à montrer.
Sachez que quelques correctifs de bugs à gauche et à droite, sur un ou plusieurs projets, cela a de la valeur aussi. Il n'y a pas d'injonction à la réussite dans ce schéma là. Vous butez sur un bug coriace ? Vous pouvez toujours faire machine arrière et en choisir un autre à résoudre. Ce projet ne vous plait plus ? Trouvez en un autre. Et chaque bug résolu, chaque nouvelle fonctionnalité développée sera une munition supplémentaire, vérifiable, pour convaincre votre possible employeur que vous êtes faite pour le job.
# J'abonde
Posté par Zenitram (site web personnel) . Évalué à 10.
En tant que potentiellement employeur, j'abonde.
Clairement, ce n'est pas que chacun ait un projet (pas assez de projet intéressant pour ça, un bon projet prend beaucoup de temps etc), mais montrer publiquement ses capacités tout en participant au libre.
Perso ça m' "amuse" tous ces gens qui disent "je suis sensible au libre" mais qui considèrent juste que le libre = gratuit en pratique (ils prennent, mais ne diffusent rien). Quand tu as une sensibilité au libre, ça se voit ;-).
Bref, ce n'est pas parce que vous êtes débutant que vous n'avez rien à montrer quand vous êtes sensible au libre, au contraire (je me souviens très bien du temps libre que j'avais pendant mes études ;-) et de ce que j'en ai fait et qui m'a amené là où je suis).
# À bas les roues en bois
Posté par Julien Jorge (site web personnel) . Évalué à 10.
Cet argumentaire de « ne pas réinventer la roue » est pour moi un automatisme malvenu que les gens de conseil sortent à tout va pour se donner du crédit. Je pense au contraire que si tu es débutant tu as tout intérêt à réimplémenter des choses existantes ; c'est ce qui te fera passer du stade « connaître » au stade « comprendre ».
À titre d'exemple, j'ai appris à l'école ce qu'étaient des arbres binaires équilibrés mais ce n'est qu'en implémentant un AVL que j'ai compris comment ça fonctionnait. Pourtant mon implémentation n'était qu'une roue mal fichue, mais je l'ai utilisée, j'ai rencontré des problèmes qui m'ont amené à encore plus de réflexion, je l'ai confrontée à des outils plus mûrs pour en apprendre d'avantage.
J'ai aussi codé le chargement d'images bmp, tga, pcx, gif et autres. Cela n'a aucun intérêt dans un projet puisque de nombreuses bibliothèques le font déjà bien et que certains formats sont complètement obsolètes, et en plus je connaissais déjà tous ces formats. Et pourtant ça m'a fait me confronter au RLE, à LZW, à la question de la représentation des couleurs, aux formats palette, rgb16 et autres. À l'époque je confrontais mon code aux temps de chargement d'ACDSee, ce qui m'a amené à la question de l'optimisation. C'était aussi un bon exercice de suivi de specs puisque tous ces formats sont bien définis et que les documents techniques sont disponibles. Il y a en particulier plein de variantes de gif et j'avais dû rassembler de nombreux exemples pour valider l'implémentation.
Réinventer la roue c'est aussi apprendre à gérer un projet. Si tu te dis, par exemple, « je vais implémenter une messagerie instantanée » tu vas devoir poser un cadre. Est-ce que le client tourne dans un terminal, une app desktop, un navigateur ? Comment le serveur fonctionne-t-il ? Gères tu les sockets toi-même, utilises-tu des bibliothèques pour cela ? Est-ce que tout passe par le serveur ? Est-ce du pair à pair ? Comment gères-tu la sérialisation ? T'appuies-tu sur un protocole existant ?
Savoir poser des limites, sélectionner des fonctionnalités et cadrer le projet pour l'amener à terme, c'est aussi quelque chose qui se comprend en pratiquant.
Enfin même de manière professionnelle il m'est arrivé de réimplémenter des choses pour des raisons de coût : nous commencions avec l'outil d'un tiers puis nous le remplacions par quelque chose rendant le même service pour un coût moindre et des performances meilleures.
Moi je crois que les bons sportifs ne sont pas dans les gradins à manger des chips. Je crois que les bons musiciens jouent tous les jours, reprennent des morceaux existants qu'ils jouent du mieux qu'ils peuvent, avec des accords ratés et en passant à côté de subtilités. Ce n'est sans doute pas aussi bien que le morceau original mais ça peut quand même être une belle reprise, et surtout ça les rend meilleurs à ce qu'il font.
Alors si tu es débutant, et d'ailleurs ça marche aussi si tu es expérimenté, et que tu réponds à une offre de la boîte où je travaille, mon conseil est d'avoir :
[^] # Re: À bas les roues en bois
Posté par Glandos . Évalué à 10.
Réinventer la roue est une part du processus pédagogique. Dans tous les apprentissages, on (re)fait des choses déjà faites des milliers de fois par les prédécesseurs. On apprend encore le calcul mental là où les calculateurs électroniques sont bien plus performants.
Mais, revenons au développement des logiciels. Réinventer la roue, c'est nécessaire pour savoir une chose (en dehors de l'apprentissage profond d'une technique particulière) : quand est-ce qu'il ne faut pas réinventer la roue. J'ai vu des gens dans mon travail recoder des tables de hachage en Java ou en C#. J'ai vu trop de gens ne même pas imaginer que le problème qu'ils ont face à eux est un problème commun, forcément résolu ailleurs, avec un meilleur recul et plus d'expérience.
Par contre, mettre dans son CV un truc qui montre qu'on a réinventé la roue, je ne sais pas si c'est vendeur en effet. La réflexion n'est pas terminée ;)
[^] # Re: À bas les roues en bois
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 3.
Je pense que vos deux avis ne sont pas opposable.
Il faut commencer par quelque chose. Et ne jamais hésiter à gravir le mur.
Il ne faut pas non plus hésiter à revenir en arrière, ou a abandonner.
L'apprentissage, c'est 90% d'échecs (mesure prise sur mon pifomètre). Et c'est pas grave, du moment qu'on en retire quelque chose.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: À bas les roues en bois
Posté par liberforce (site web personnel) . Évalué à 10.
Tout à fait, les deux approches ne sont pas contradictoires, mais elles s'inscrivent pour moi dans deux contextes différents: pédagogie vs commerce.
Dans un cadre pédagogique, réimplémenter quelque chose qui existe, c'est important pour le comprendre. Je me souviens avoir eu à écrire ma propre implémentation de listes doublement chainées à l'école. C'était cool, et ça m'a aidé à en comprendre les subtilités. Des fois tu crois avoir compris quelque chose, mais si tu n'es pas capable de le refaire, c'est que tu n'avais pas tout compris. Faire des choses c'est important pour le processus pédagogique, on a tous eu des Travaux Pratiques à l'école.
Le sens de ma remarque "ne réinventez pas la roue carrée", c'est qu'à moins que ce ne soit dans un but purement pédagogique, cela a peu d'intérêt. Le résultat aura de la valeur pour vous, mais elle sera affective surtout, car c'est plus le chemin que la destination qui est important. Cela vous aidera pour un test technique par exemple, grâce à l'expérience accumulée, et au fait de pouvoir se dire "hé, j'ai déjà fait quelque chose de similaire !".
Cependant, dans un contexte commercial, votre roue carrée n'intéressera pas forcément un potentiel employeur. Ils aiment les jolies roues rondes, et une roue carrée tout moche qui roule mal, c'est pas très vendeur.
En conclusion, plutôt que de développer "montube", votre clone de youtube, bin contribuez plutôt à PeerTube, ce sera plus utile et vendeur je pense :-)
[^] # Re: À bas les roues en bois
Posté par mothsART . Évalué à 1. Dernière modification le 24 mars 2021 à 12:15.
Je comprend ton point de vue mais j'aurais tendance à être plus nuancé.
Ré-implémenter quelque chose peut avoir pas mal d'intérêts.
Si déjà tu le fais dans un autre langage, ça peut apporter bien plus de valeur que de la pédagogie.
Vu que je suis pas mal branché Rust ces derniers temps, je vois moultes projets réécrit en Rust pour des bonnes et des mauvaises raisons.
Par ex, rustls est une réécriture de TLS qui ne s’embarrasse pas à supporté des versions < 1.3.
Du coup, pas de legacy, c'est plus simple à appréhender, faire évoluer etc.
Une ré-implémentation, ça peut : cibler de nouvelles architectures, pouvoir être compilé en Webassembly, créer des binaires plus petits, de meilleurs perfs, une approche différente (on peut vouloir des algos diff selon contexte), toucher un autre public/communauté etc.
Alors, évidement, y'a des trucs qui dépasseront pas la valeur pédagogique mais la frontière est mince et je pense que pleins de projets toy sont devenus matures sans que ce soit prévu au départ.
D'ailleurs, un certain Linus Torvald, lorsqu'il a lancé son noyau copie presque conforme de Minix, n'a sans doute pas anticipé sa popularité.
[^] # Re: À bas les roues en bois
Posté par liberforce (site web personnel) . Évalué à 3.
Je ne me suis pas bien fait comprendre. Le propos est orienté vers des débutants sortis de formation, souhaitant trouver du boulot. J'ai une amie en reconversion professionnelle qui est dans ce cas là. Ré-implémenter quelque chose pour le rendre meilleur, c'est très bien. Je pense juste que tout le monde n'est pas Linus Torvalds, et que pour quelques génies, les gens normaux (dont je fais partie) préféreront un objectif atteignable rapidement, offrant une visibilité et une satisfaction à court terme. Apprendre à marcher avant de courir, quoi.
Mais une "vitrine" qui doit implémenter des choses précises pour montrer son savoir faire, ça ne colle pas forcément au projet qu'on a envie de développer, et on peut se retrouver à tenter de faire rentrer des carrés dans des ronds.
Une ré-implémentation c'est bien, mais pour son intérêt propre, en tant que projet "hobby" plus que vitrine. Et parfois des hobbys deviennent de bonne vitrine, mais ça se fait rarement en un week-end.
[^] # Re: À bas les roues en bois
Posté par Tonton Th (Mastodon) . Évalué à 4.
Et voilà, tu viens de mettre ast en colère !
[^] # Re: À bas les roues en bois
Posté par mothsART . Évalué à 1.
Ouais, tout à fait.
2 implémentations diff pour le même résultat (à 2 vaches près) côté utilisateurs : un micro-noyau et l'autre monolithique…
Au final, qui c'est qu'à gagné (pendant au moins 30 ans… je dis pas qu'un jour ça ne pourrait pas s'inverser) : la théorie ou la pratique ?
[^] # Re: À bas les roues en bois
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
La théorie pratique
:-)La pratique théorique(-:“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: À bas les roues en bois
Posté par barmic 🦦 . Évalué à 7.
Je ne suis pas forcément d'accord. Autant moi j'aime coder sur mon temps libre autant je ne me vois pas imposer ça à quelqu'un d'autres. La situation personnelle, la difficulté d'organisation ou même le goût peuvent facilement empêcher ça sans pour autant que ça me paraisse gênant dans le cadre de l'entreprise.
Pareil.
Je pense même qu'il est important de ne pas avoir que des névrosés du code (comme je peux l'être) dans une équipe. Ça contribue, entre autre, à la multiplicité des points de vu et des compétences et puis ça aide à l'équilibre au sein d'une équipe.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Argument supplémentaire
Posté par Colin Pitrat (site web personnel) . Évalué à 10.
Un argument que tu ne développes pas, c'est qu'en codant seul dans son coin, on reste aveugle à certains de ses défauts.
En contribuant, le code sera en général revu et on recevra des conseils qui permettront de se remettre en question et de progresser. D'explorer des solutions dont on n'aurait même pas eu l'idée.
[^] # Re: Argument supplémentaire
Posté par Colin Pitrat (site web personnel) . Évalué à 10.
Et aussi: savoir aborder une base de code existante, comprendre comment elle est structurée et comment trouver la bonne partie à modifier, c'est un savoir faire utile qui s'acquiert par l'expérience.
[^] # Re: Argument supplémentaire
Posté par mothsART . Évalué à 7.
Clairement. S'interfacer sur une base de code existante sans casser ni réécrire des pans entiers c'est bien plus délicat qu'avancer sur son petit projet avec son code qu'on connait bien.
Il y a en effet plein d'avantages à participer à des projets open-source (le libre reprend les mêmes bénéfices et en rajoute d'autres) :
[^] # Re: Argument supplémentaire
Posté par Philippe F (site web personnel) . Évalué à 10.
Et surtout, c'est exactement ce qu'on attend en général de toi en entreprise : arriver sur une base de code existante de l'entreprise, et s'insérer dedans.
J'ai constaté que mon habitude de lire le code sources des logiciels libres m'a permis d'être assez performant dans mes débuts pour m'approprier la base de code propriétaire de l'entreprise. Un vrai plus par rapport à mes collègues, qui parfois même là depuis plus longtemps que moi, n'osaient pas ou n'avait pas suffisamment l'habitude de le faire pour que ce soit efficace.
[^] # Re: Argument supplémentaire
Posté par bbo . Évalué à 6.
Absolument. Savoir naviguer dans un océan de legacy est une vraie compétence.
[^] # Re: Argument supplémentaire
Posté par claudex . Évalué à 5.
Je dirais que c'est le plus difficile. Trouver des bugs/fonctionnalités qui nous impact nous et d'autres personnes. Ça m'est déjà arrivé pas mal de fois de chercher dans les bugs tracker, mais la plupart du temps, je tombe sur des bugs non-reproductibles avec ma configuration ou des fonctionnalités qui ne m'intéresse pas (et donc pas motivant et difficile de trouver une implémentation correcte pour un cas d'usage qui m'est étranger).
Donc, un bon conseil serait: Comment contribuer à un logiciel existant à part "je l'utilise et je rencontre un bug assez facile à corriger".
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Passer du bon temps
Posté par anaseto . Évalué à 8.
Une idée que tu ne développes pas, mais qui me semble importante, c'est que programmer sur son temps libre, c'est à mon avis mieux si c'est fait par plaisir sur des choses qui nous concernent. Si l'objectif principal, c'est de se créer une e-réputation, ça risque de ne pas nous satisfaire pleinement et d'être décourageant.
Donc concernant les correctifs de bugs à gauche ou à droite, c'est mieux si c'est sur des projets qui nous tiennent à cœur, et encore mieux s'il s'agit de bugs qu'on a rencontré soi-même ou bien qu'on a échangé avec des gens qui ont rencontré le bug. En le corrigeant, ça donne une sensation d'accomplissement qu'on n'obtient pas si on corrige juste un bug au hasard. Lorsque je corrige un bug qui gêne un utilisateur que je connais (au moins un peu) ou avec qui j'ai eu des échanges, il y a un côté social qui fait que je suis plus content.
Après, concernant les projets solo, c'est vrai que ça risque de pas aboutir. Mais avec l'expérience, on apprend à définir des objectifs raisonnables, un ou deux échecs au début, c'est pas si grave. C'est moins utile pour se créer une e-réputation, vu que ton travail n'aura que peu de visibilité, mais c'est sympa, ça développe des compétences différentes, et il y a moins de pression (ce qui, pour une activité sur du temps libre, n'est pas si mal). C'est, par contre, à mon avis, sympa d'essayer d'avoir quelques utilisateurs en plus de soi-même, histoire d'avoir des échanges quand même.
# e-réputation et code public
Posté par jben . Évalué à 10.
Il a été abordé deux points, dans le sujet du journal et dans les commentaires :
Ces deux points ne sont pas exclusifs et ça a été souligné. Mais il y a un point que j'aimerai mettre en avant il faut que les postulants fassent attention à leur réputation publique. Je pense en particulier à tous les codes de projet étudiants (qui sont des réimplémentations de la roue carré, faits dans un but pédagogique, pas dans un but de réécriture/refactoring/whatever), qui ne doivent pas être public. Cela donne une mauvaise image et cela brouille les vrais contributions.
Je suis enseignant-chercheur dans une école d'ingénieur, et même si mon domaine n'est pas de l'info au sens dev, et que ce n'est pas à moi de faire passer ce genre de message en interne, je suis toujours étonné des profils publics des étudiants. Un exemple flagrant, c'est un étudiant ayant un super bon profil technique (en plus d'un bon profil scientifique) qui était présent sur github. Quand on regarde sa page github, on trouve nombre de projets perso ou contributions sur des projets qui ne sont que des projets étudiants dans le cadre des enseignements, et souvent de pietre intérêt générale et de pauvres qualités techniques. Alors que dans le même temps, cet étudiant avait contribué de manière significative à
scikit-learnet àsympy(pour ceux qui ne connaissent pas, deux grosses bibliothèques en python scientifique), et ces contributions étaient invisibles et noyées dans la masse des contributions inutiles et bidons sur des projets étudiants.J'approuve donc le contenu du journal, contribuez sur des gros projets, mais faîtes attention aussi à votre réputation et que ces contributions ne soient pas noyés dans la masse de contributions qui n'en sont pas quand on fait une recherche sur votre nom.
[^] # Re: e-réputation et code public
Posté par mothsART . Évalué à 4. Dernière modification le 27 mars 2021 à 12:17.
Pour moi, le piège de la réputation publique n'est pas forcément de ce côté…
Le gars qui a des profils insta, facebook, whatever avec des contenus pas très pro (beuverie, contenus NFSW etc.) va se décrédibilisé beaucoup plus vite.
Pour les contenus médiocres, j'émettrais une réserve : si on participe a des projets libres par exemple, on va pas forcément que faire des trucs de haut vol. Néanmoins, les participations peuvent avoir du sens.
Ma crainte c'est un discours aseptisé du genre : faut être un bon morceau de viande calibré pour être présentable sur le marché du travail ! (désolé pour la caricature)
Si je fais un peu d'instropection et que je définit pourquoi j'ai été séduit et que je continue à faire du dev, je pourrais dire :
la créativité, la curiosité, l'amour de l'apprentissage, le dépassement de soi, l'accomplissement, pour le logiciel libre : certaines valeurs d'équité et de partage etc.
Du coup, la passion qui m'anime n'est pas poussé par des trucs ultras rationnels du genre : qualité technique avant tout.
Alors, bien évidement, toutes ces motivations m'ont donnés des accès à des embauches dans le domaine.
Néanmoins, je ne pense pas que c'était "calculé" dans le sens ou toutes mes actions étaient faites dans le but d'intégrer tel ou tel boite.
En plus, je considère que au niveau pro, même au sein d'entités très prestigieuses, le quotidien n'est pas que fait de trucs très "hype".
La réalité c'est aussi pas mal de tâches répétitives, de legacy, de paperasse, de réunions à rallonges, d'interactions avec des nons techs etc.
Bref, ce qui pourrait sembler séduisant sur un profil github n'est en fait qu'un grain de poussière par rapport aux attentes réels.
Avec l’expérience, je trouve que des valeurs comme l'écoute, l'intelligence sociale, la remise en question peuvent être tout aussi bénéfiques voir plus que les qualités techniques purs et durs.
J'ai des exemples de personne au dessus du lot techniquement qui ont plombé des boites car il n'arrivait pas à travailler en équipe.
Pour moi, la distinction public/privé pour un repo ne concerne pas que l'aspect "vendeur" sur un CV.
Donc, le mec qui aime coder sur son temps libres des trucs fun, sans prétention, ça va pas ?
Tu suggères quoi : un compte pro (spécial vitrine) et un compte pour le reste ?
[^] # Re: e-réputation et code public
Posté par jben . Évalué à 5.
Je ne vise pas les projets perso, au contraire, c'est très bien d'avoir des projets de dev perso, (et généralement plus ils sont funs, mieux c'est). Également, je ne vise pas les contributions mineures sur des gros projets, c'est très bien les contributions mineures.
Je vise les projets étudiants qui n'ont pas vocation à être autre chose que des projets étudiants qui devraient rester privés (attention, si c'est un vrai truc initié dans le cadre d'un projet étudiant, c'est très bien que cela soit public).
Là où j'enseigne, les étudiants ont certains semestres, pas mal de projets (mais moins que dans certaines autres) dans le cadre des enseignements, qui sont à vocation à uniquement former les étudiants, pas à être visibles. Sur quelques semestres, cela commence à faire pas mal en volume et à noyer ce qui est pertinent.
[^] # Re: e-réputation et code public
Posté par mothsART . Évalué à 2.
Ok, je comprend et j'approuve !
[^] # Re: e-réputation et code public
Posté par jben . Évalué à 4.
Sur ce point, je suis assez optimiste. La majorité des étudiants que je côtoie ont compris ces enjeux et ne font pas n'importe quoi avec leur profil public sur les réseaux sociaux.
# Ou pas
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Je pense que ca depend du job recherche'. Je trouve que participer a un LL, ca montre surtout du code brut, mais ca manque gravement en "design". Je pense qu'il y a beaucoup d'interet a` coder des applications qui utilisent le cloud, et montrent des systemes asynchrones. Si tu postules pour un GAFA, tes chances de succes sont meilleures avec un projet DynamoDB/S3/ECS/Lambda et du "leetcode" que si tu repares des bugs dans une application libre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.