arnaudus a écrit 5317 commentaires

Est-ce que ça existe seulement, un logiciel qui n'a pas de "contrainte particulière"? Tout logiciel a un contexte d'utilisation, qui pondère l'importance des différents critères: clarté du code, performance RAM, performance CPU, évolutivité, expérience utilisateur, fiabilité, etc. Je ne vois pas ce qui ferait qu'automatiquement, le nombre de bugs ouverts serait le critère à optimiser en priorité. Même, au contraire, quel type de logiciel devrait avoir ce critère prioritaire? Les systèmes embarqués ou les systèmes d'aide à la décision, quand des vies humaines, du matériel qui coûte cher, ou des gros capitaux sont en jeu? Mais sur les logiciels courants (traitement de texte, IDE, navigateur, jeux vidéo, compilateurs…), si les bugs ne nuisent pas à l'utilisation (par exemple s'ils sont facilement contournables ou qu'ils concernent des fonctionnalités avancées dont on peut se passer), il est difficile d'imaginer une raison pour laquelle les ressources devraient être consacrées exclusivement à la correction des bugs.

J'aurais donc tendance à considérer que la priorité aux bugs relève de "contraintes particulières". D'ailleurs, beaucoup des logiciels qu'on utilise sont buggés, sans que les équipes de développement s'en émeuvent particulièrement.

Avoir le moins de bugs possible.

Bah déja, des perfs problématiques peuvent être un bug. Si ton logiciel qui gère l'ESP d'une voiture réagit quand la bagnole est déja dans le fossé, c'est une sorte de bug.

Ensuite, je ne suis même pas d'accord. Il y a des logiciels pour lesquels une certaine catégorie de bugs est largement acceptable. Typiquement, c'est le cas des logiciels de rendu: quand Latex te sort des oversize box et te fait dépasser le texte dans la marge, c'est un bug; quand lilypond to sort un truc bof bof, c'est un bug (le rendu s'améliore d'ailleurs de version en version). En tout cas, ce genre de dysfonctionnement est inhérent à la complexité de certaines tâches, et c'est acceptable d'en avoir un certain nombre par rapport à d'autres critères à privilégier (par exemple, le temps d'exécution, ou la clarté des algorithmes). On pourrait aussi citer l'optimisation par les compilateurs par exemple, où il y a toujours un compromis entre l'efficacité et le temps de compilation. Des heuristiques de pathfinding, qui ne te donnent pas forcément le chemin optimal, mais qui font un compromis avec les perfs. Il semble y avoir une infinité d'exemples où une tâche peut ne pas être parfaitement exécutée et où un tel compromis est acceptable.

Du coup, "minimiser les bugs" me semble être un critère parmi d'autres à optimiser, et le poids respectif de ces critères dépend du contexte.

ChatGPT excelle à ce qu'il est censé faire (la conversation). Il n'est pas un moteur de recherche encyclopédique, donc il peut raconter n'importe quoi.

Il faudrait évidemment demander son avis à un spécialiste, mais j'ai l'impression que c'est théoriquement très faisable d'entrainer une AI à retrouver des informations dans un texte, surtout un texte comme une décision de justice, qui reste très formelle. À la lecture des quelques informations présentes sur les diapos, j'ai l'impression que la solution logicielle a plutôt été une sorte de système expert, qui s'est heurté à des problèmes triviaux (comme l'utilisation de différents séparateurs dans les nombres), chose qui en théorie ne devrait poser aucun problème à un réseau de neurones. Après, encore une fois, je ne suis pas du tout spécialiste, je constate juste qu'il y a une énorme différence entre "c'est impossible" et "on n'a pas su le faire".

Pour les erreurs éventuelles d'un système automatique, il faudrait surtout les comparer au taux d'erreur d'un humain qui retranscrirait ces informations. Étant donné les objectifs (établir un barème moyen des indemnisations), j'ai l'impression que la présence d'erreurs ne serait pas particulièrement problématique (il faudrait évidemment confirmer manuellement les outliers, mais c'est normal).

De ce que j'ai pu voir en survolant les slides, une question majeure n'a pas été abordée : quid de la qualification de l'équipe en charge du projet?

Parce que l'AI, c'est pas magique. Mais quand c'est mis entre les bonnes mains, ça marche. Je ne peux pas croire qu'il est possible d'un côté de faire des choses aussi complexes que ce que fait chatGPT, et d'un autre côté d'être infoutu de parser des décisions de justice, qui font partie des documents les plus formels qui existent.

C'est peut-être une histoire de budget ou de ressources (par exemple, quelle est la taille du jeu de données d'entrainement, interprété par des humains?), c'est peut-être une histoire d'algo (modèle de langage, etc), mais non, je ne peux pas croire que ça a foiré parce que "ouhlala le problème était trop dur". Ça ressemble plutôt à "les gens à qui ça a été confié ne savaient pas le faire".

Je ne suis pas forcément d'accord sur les deux constats écologiques.

D'une part, le problème des énergies fossiles n'est pas qu'elles sont en quantité limitée, mais plutôt qu'il y en a encore trop sous terre. Il faut donc arrêter de les exploiter bien avant qu'on n'en ait plus. Par ailleurs, ce sont principalement les transports qui sont shootés aux énergies fossiles. La production industrielle l'est en général beaucoup moins (si l'électricité est décarbonée, ce qu'on sait faire).

D'autre part, la pénurie de métaux en général est quand même assez virtuelle. Bien sûr, il y a quelques métaux critiques pour lesquels on n'est pas sûrs d'avoir des réserves pour les 30 prochaines années, mais il y a peu d'utilisation industrielle de métaux irremplaçables. C'est juste une histoire d'offre et de demande; quand certains métaux deviendront plus durs à extraire, leur prix va augmenter, et les industriels les remplaceront par d'autres alliages, peut-être un peu moins performants, mais moins coûteux. Et quand on parle de machines à laver, le fer reste virtuellement illimité, donc on ne va pas du jour au lendemain passer au tout plastique.

Dans ce cas, a était (indirectement) un paramètre (0.0 par défaut). Du coup, il était tout à fait crédible que a soit exactement 0, et ça avait du sens de gérer cette situation. Je préfère largement ça à un paramétrage redondant (style un switch booléen, et une variable numérique qui n'a de sens que si le switch est activé).

J'aurais eu plus de doutes pour une variable différente de 0, style 1.0. En théorie, si on est carré sur les types, j'imagine que c'est possible d'avoir un test exact, parce que la représentation binaire ne devrait pas changer (si le fichier de paramètres contient MAVAR=1.0, qu'on lit ça avec >> pour mettre dans un type à virgule flottante, qu'on ne transtype pas et qu'on finit par tester == 1.0, j'ai l'intuition que ça devrait marcher). Mais avec 0.0 ça doit forcément marcher, sauf s'il y a une gestion vraiment déconnante des types à virgule flottante.

Le pire dans cette histoire, c'est que même si le test ne fonctionnait pas comme prévu (si a était le résultat d'un calcul numérique, style a = 3.0 - sqrt(9.0)), l'algo restait tout à fait fonctionnel (il aurait multiplié par 1e-32 et aurait obtenu quelque chose du même ordre de grandeur). Il n'y avait donc aucune raison de partir en vrille.

si les cas où l'optimisation se déclenche était trop rare par rapport au reste, ça resterait une optimisation discutable.

J'imagine qu'en théorie la prédiction de branches permet justement de faire en sorte que ça marche. Mais j'ai eu l'impression (ce n'est qu'une impression, je n'ai pas analysé plus que ça) que dans tous les cas les deux branches étaient calculées (peut-être parce que le nombre de cycles nécessaire était inférieur à un critère que je ne connais pas), et que la version avec if() nécessitait de revenir en arrière alors que le coût du calcul était de toutes manières déja passé.

J'ai aussi à mon actif quelques cas de mémoïsation ratés, parce que ça coûtait plus cher d'aller chercher un résultat dans une table que de calculer une fonction non-triviale. C'est probablement des cas très classiques pour des gens dont le métier est d'optimiser des algorithmes (typiquement, des algos en O(1) en pratique plus lents que des O(2) à cause d'un coût initial), mais quand on n'est confrontés que sporadiquement à des problèmes d'optimisation, c'est toujours destabilisant.

Merci d'avoir lu ce que j'avais écrit, je commençais à me demander si on parlait la même langue…

Je voulais juste donner un exemple d'optimisation prématurée qui ne fonctionnait pas, et insister d'une manière générale sur la difficulté de prédire les perfs d'un compilateur et d'un processeur moderne dans un contexte non-trivial (branchement vs calcul). Donc au final, coder clairement et laisser le compilateur gérer, c'est exactement le message que je voulais passer.

Pourquoi? Qu'est-ce qui empêcherait ce coût d'être élevé en cas d'abus d'héritage (allez, disons qu'il y a 10 niveaux d'héritages, 5 fonctions virtuelles à chaque fois, et que chaque couche a plus de classes que sa couche parente…), de fonctions virtuelles, de dynamic_cast?

Je suis d'accord que ça n'est pas totalement impossible. Mais on parle de nanosecondes. Donc oui, on va peut-être perdre des millions de nanosecondes. Il n'empêche que ça reste imperceptible, parce que le temps d'exécution, en réalité, c'est des cache miss, des accès disques, des appels système, etc. C'est assez perturbant de voir à quel point les processeurs sont rapides, en fait.

Ça me rappelle une discussion avec notre ingé système, qui n'était pas content quand on lançait 300 exécutables sur un serveur de 100 cœurs. Ça fait péter le load average (et ça fait clignoter ses alarmes), et en théorie les context switch sont coûteux. Et en effet, ça fait des dizaines de milliers de context switch… qui font perdre quelques dizièmes de microsecondes chacun. Donc au final, moins d'une seconde sur des jobs qui tournent sur 3 jours. C'est toujours une histoire d'ordre de grandeur, faire des millions de fois des choses inutiles qui durent 10 milliardièmes de secondes, c'est complètement instantané. Par contre, faire un milliard de fois quelque chose qui prend une microseconde, ça fait planter la machine.

Lecture intéressante. Je trouve qu'il y a beaucoup de mauvaise foi chez ce Casey; en fait, il a une idée fixe, et il essaye de torturer les réponses pour faire rentrer son idée fixe. La discussion est pleine de sous-entendus fallacieux, ç'en est perturbant. Par exemple, Casey essaye de systématiquement donner des exemples de logiciels dont le manque de réactivité est problématique (Microsoft Word, des IDE, etc), comme si ce manque de réactivité était une conséquence directe du fait qu'ils étaient codés selon les principes du Clean Code.

Sur le fond, je trouve que Martin est beaucoup plus convainquant. Les bloatwares sont lents parce qu'ils sont mal conçus, et qu'ils seraient probablement mieux conçus s'ils suivaient le principe du Clean Code. Le coût des appels de fonctions et des tables virtuelles ne peut qu'être totalement négligeable pour de tels logiciels, leur lenteur ne peux être qu'un problème de conception et/ou de ressources externes (biliothèques graphiques?).

tandis qu'un passeport d'espion sous couverture légende, émis par une vraie préfecture française, est un faux intellectuel par exemple.

Pas certain que ça passe par les préfectures.

SAS est drôle, pourtant.

Le peu que j'ai appris sur ces histoires d'optimisation, c'est

1) Laisser le compilateur faire son job (donc, coder très clairement)
2) Utiliser les paradigmes du langage

Pour le 1 par exemple, je n'arrive toujours pas à bien réaliser à quel point les branchements sont coûteux par rapport aux calculs. Pendant longtemps j'ai écrit des trucs du style:

 double ans = 0.0;
 if (a != 0.0)
  ans = a*log(truc)/(sin(bidule)-pow(machin, 3.7));

et ça s'est avéré désastreux en termes de perfs, parce les processeurs modernes sont justes très, très, très rapides pour les calculs.

Pour le 2, ça me gonflera toujours autant d'entendre 'tel langage est lent'. Il n'y a pas de langages intrinsèquement lent (évidemment, les trucs interprétés sont toujours moins performants, mais pour la plupart des applications même un facteur 10 ne se voit pas). Par contre, il y a des langages qui ont des paradigmes différents, et si on code tout comme en C, on va voir apparaitre des ralentissements insupportables ; ça n'est pas un problème du langage.

Pareil que moule ou poële, non? C'est la même étymologie (latin spatium), donc c'est le même mot, il n'y a qu'une entrée dans le dictionnaire.

Ce ne doit pas être le seul.

alvéole, après-midi, enzyme, météorite, oasis, palabre, parka, perce-neige, réglisse

D'autres changent de sens :

espace, livre, manche, voile, moule, poêle

Pour ceux qui changent au pluriel, il n'y a guère que "amour" qui pose encore problème (pour "orgues", ça n'est féminin que dans l'expression figée "grandes orgues", et pour "délices", plus personne ne met le pluriel). Mais que fait-on pour "un(e) de mes plus belles amours"? :-)

Résultat, c'est tellement arbitraire et stupide (justifier son domicile pour un passerport, quel est le crétin qui a eu cette idée d'ailleurs ?)

Tu confonds (volontairement?) "logique" et "arbitraire", et je n'irai pas plus loin dans cette discussion. Personne ne t'a demandé d'être logique, et le boulot des fonctionnaires de mairie et de préfecture n'est pas d'être logique. Il y a un décret qui liste les pièces nécessaires et les justificatifs acceptés, si tu fournis les pièces nécessaires ton dossier passe, si tu fournis d'autres pièces ton dossier ne passe pas. C'est le contraire même d'arbitraire. Tu as la chance de vivre dans un pays où tu peux trouver des listes officielles de documents nécessaires, tu peux retrouver dans quel décret elles sont listées, qui a rédigé le décret; tu as la possiblité de faire des recours contre ces décrets, tout est carré, officiel, documenté, et transparent.

L'alternative, c'est qu'un petit fonctionnaire local décide en fonction de ses critères perso (et de la taille du billet que tu as glissé dans ton dossier) si tu vas avoir ton passeport ou pas, et franchement, je préfère très très très largement le système bureaucratique que tu conchies.

Je conçois très bien que tu ne comprennes pas pourquoi il faut un justificatif de domicile pour les passerports, ou pourquoi les factures de téléphone sont des justificatifs de domicile alors que les factures internet ne le sont pas. Moi non plus je ne comprends pas, mais je n'insulte pas la terre entière à chaque fois que je ne comprends pas quelque chose.

Par exemple, pour l'adresse au jour de la délivrance du passeport, c'est une obligation imposée par le Décret n° 2005-1726 du 30 décembre 2005 relatif aux passeports électroniques; qui implémente une liste imposée par l'Organisation de l'aviation civile internationale. Si tu veux changer ça, il faut donc remonter assez haut…

Pour les justificatifs de domicile, ça a quand même beaucoup progressé. Maintenant on peut facilement se faire exempter si on s'identifie (via le site des impôts par exemple) lors de la pré-demande de passeport.

Tout dépend de quand ton expérience date, mais le témoignage laisse à penser que l'acceptabilité d'un justificatif de domicile est arbitraire, ce qui est quand même complètement faux. Par exemple, pour la quittance de loyer, il est bien précisé dans les documents officiels "Quittance de loyer d'un organisme social ou d'une agence immobilière", donc il n'a jamais été question qu'une quittance signée par un propriétaire privé puisse valoir justificatif de domicile. De même, les factures de téléphone, de gaz, ou d'électricité figurent dans la liste, mais pas les factures internet. Tout ça est fixé par décret (*), l'état de droit est parfois agaçant, mais ceux qui ont essayé autre chose s'en mordent les doigts.

(*) en l'occurrence, le décret 2005-1726 du 30 décembre 2005 relatif aux passeports précise "Le demandeur justifie de son domicile ou de sa résidence par tous moyens, notamment par la production d'un titre de propriété, d'un certificat d'imposition ou de non-imposition, d'une quittance de loyer, de gaz, d'électricité, de téléphone ou d'une attestation d'assurance du logement." Il existe donc une possibilité théorique de fournir un autre document—c'est certainement pour ça que la mairie peut accepter des documents qui ne sont pas dans la liste. Ceci dit, on prend le risque que la préfecture refuse le dossier, et les employés de mairie ont probablement une idée assez nette de ce qui passe et ce qui ne passe pas.

hop, on corrige le billet d'avion et ça passe comme une lettre à la poste.

Il faut aimer vivre dangereusement quand même, parce que certains exemples sont vraiment limite. Je pense que le coup du billet d'avion tombe dans la définition de "faux", et le risque de se faire coincer à l'arrivée est substantielle (par exemple, le billet retour est parfois demandé par la douane pour justifier d'une exemption de visa). Une déclaration frauduleuse peut valoir une exclusion de visa à vie dans certains pays (USA), et il n'y a aucune garantie que la définition française du faux (définie par ses conséquences) soit la même partout. Et il reste un risque de toutes manières de ne pas pouvoir monter dans l'avion, car la compagnie vérifie les noms à l'embarquement.

Ceci dit, ça pourrait être pas mal de pouvoir rentrer son numéro de passeport lors de l'achat du billet, avec remplissage automatique des champs. Ça éviterait ce genre de gags.

Le problème de la manivelle, c'est que soit tu incrustes une manivelle télescopique ridicule dans la monture du volet (le truc impossible à utiliser dans la panique), soit il faut y accrocher une grande manivelle (mais évidemment, en cas d'incendie, va retrouver le truc à la cave).

Le plus simple serait peut-être une poignée de secours comme dans les trains, tu tires dessus et ça déboite la fixation du volet que tu peux faire tomber vers l'extérieur. C'est un one-shot mais c'est le plus rapide. Par contre, si ça se trouve c'est plus dangereux de faire tomber un volet (par exemple sur les pompiers 6 étages en dessous) que de coincer les gens à l'intérieur.

J'ai cherché vite fait, mais je n'ai pas trouvé si une pile 9V pouvait faire l'affaire. Un moteur de volet roulant c'est 100 à 200W, donc une pile complètement chargée pourrait délivrer 100W pendant 3 minutes, en théorie ça suffirait, mais ça m'étonnerait que la pile puisse délivrer 10A (je n'y connais rien en électricité).

Apparemment ça existe, ça s'appelle des moteurs CSI (commande de secours intégrée), il faut une configuration particulière (pour pouvoir mettre une manivelle), ça ne rentre pas dans toutes les fenêtres. Et tu perds en protection contre les intrusions. Et il faut quand même que tu aies la manivelle sous la main, il ne faut pas que le feu prenne trop vite.

Donc au final, ça ne sert peut-être pas à grand chose. Est-ce que ça n'est pas le genre de cas où on surestime le risque (un peu comme se noyer dans une voiture 3 portes? Ça fait super peur, mais dans les faits ça n'arrive que très rarement?).

Est-ce qu'il ne pourrait pas y avoir un dispositif de secours avec une petite batterie (type pile 9V) et un moteur démultiplié? Ça prendrait plus de temps pour s'ouvrir, mais au moins ça s'ouvrirait.

j'ai vu récemment encore passer une histoire de volets roulants électriques qui condamnent les habitants d'une maison lors d'un incendie qui a coupé le courant.

Ça n'a un peu rien à voir avec la choucroute, non? Pour les volets roulants, c'est un problème de sécurité (l'ouverture des portes repose sur un moteur qui a besoin d'électricité, or il est fréquent que l'électricité saute lors d'un incendie, et les volets manquaient d'un dispositif de débrayage). La possibilité de débrayer un équipement électrique est assez standard, par exemple sur les portails électriques, et c'est plutôt un problème de règlementation dont on parle (il faudrait que ce soit obligatoire sur les volets roulants). On peut trouver de très nombreux autres problèmes similaires, par exemple les fenêtres qui ne s'ouvrent pas dans de nombreux bâtiment modernes, l'impossibilité de s'extraire d'une voiture 3 portes en cas de chute dans un cours d'eau, etc. C'est une histoire de compromis entre les coûts, la sécurité, le fonctionnement habituel du mécanisme, etc.

Le problème évoqué avec les équipements connectés est tout autre, à mon avis. Il s'agit de déterminer quel comportement doit avoir l'objet en cas de panne partielle (comme une coupure du réseau). Le problème me semble plus général d'ailleurs, est lié à un mauvais design (mauvaise gestion informatique des erreurs) des appareils. Par exemple, le scanner qui ne fonctionne plus quand l'imprimante n'a plus d'encre, ou le logiciel qui refuse d'ouvrir un fichier parce que le disque est en lecture seule. Ça peut être volontaire ou involontaire, mais ça nuit à l'utilisateur en l'empêchant artificiellement d'utiliser un produit. Dans certains cas, ça semble facile à régler, dans d'autres (en particulier quand il y a un problème de sécurité) c'est plus compliqué : doit-on autoriser une voiture à rouler quand un capteur de pression de pneu indique une crevaison? Quand une sonde détecte un problème de moteur? Quand la direction assistée ou l'ABS est HS?

Non, mais je sur-réagis parce que j'ai été ulcéré du culot des gens de la Criirad. Ce n'est pas inhabituel pour des associations militantes de déformer un peu la réalité, mais là, c'est vraiment de l'escroquerie. Leur mesure de tritium est 1000 fois sous la limite de potabilité (et pourtant, ils mesurent dans la rivière, donc pas du tout dans l'eau potable), qui est elle-même très en-deça de la limite de dangerosité. La seule conclusion possible de leur étude c'est que les rejets radioactifs sont extrêmement limités, très en-dessous des normes, et sans aucune conséquence pour la santé, pour la faune, et pour la flore. Au lieu de s'en réjouir, ces fumistes tentent de faire croire que ces rejets sont inquiétants. Pourquoi? Parce qu'ils vivent de la peur de la radioactivité. Susciter cette peur est la condition de leur survie, et ils semblent n'avoir aucune limite dans la malhonnêteté pour y parvenir.

Je pense sincèrement qu'ils préfèreraient que les centrales émettent réellement de la radioactivité, qu'il y ait des accidents nucléaires, et que les gens aient des cancers. Ça doit vraiment les embêter d'être toujours aux limites de la détection, ça n'est pas bon pour leur business et pour leur agenda politique.

Et le voir c'est manipulatoire, donc il faudrait fermer les yeux.

Je n'ai pas dit "manipulatoire", ça serait trop gentil. Ces gens sont des fumistes. Leur analyse dit justement que l'eau ne contient quasiment pas d'éléments radioactifs, et ils essayent de faire croire le contraire.

De plus, comme l'indique la fin du premier paragraphe, on ne prend pas assez de dose de radiation pour s'inquiéter d'une infime augmentation.

En fait, cette phrase n'a même pas la prétention de présenter un argument logique, on ne peut donc pas parler de raisonnement fallacieux. On vit sur une planète qui est naturellement légèrement radioactive. Il n'y a rien d'inquiétant à ça, c'est normal. Ce que tu manges est radioactif, le granite de ton plan de travail est radioactif, l'air que tu respires, l'eau que tu bois sont radioactifs. La nature est radioactive, les plantes et les animaux sont radioactifs (potassium 40 et carbone 14, principalement). Ton corps émet environ 8000Bq. Tu ne prends pas "assez de dose de radiation", ton corps peut en tolérer au moins 20 fois plus sans problème (4.5 mSv/an en moyenne pour un habitant de la France, aucun effet statistique sur la santé jamais détecté sous 100mSv). Donc non, c'est complètement irrationnel de s'inquiéter d'une infime augmentation, surtout que le tritium a très peu d'effet biologique. Les gens du Criirad le savent très certainement, mais ils ont besoin d'idiots utiles pour diffuser les peurs irrationnelles qui leurs permettent d'exister.

Et en effet, la radioactivité à haute dose peut être dangereuse, personne n'a jamais dit le contraire. À haute dose, c'est juste plusieurs millions de fois plus que ce qu'ils mesurent.

Je m'auto-réponds, parce qu'en fait c'est assez dingue : la radioactivité naturelle de l'eau de mer est de 13 Bq/L. Donc l'eau de rivière en aval de la centrale n'est pas plus radioactive que l'eau de mer. En fait, les mesures confirment que la centrale ne rejette quasiment rien.

Le droit d'auteur sur les photos est bien établi.

Oui, mais sur les photos prises par des systèmes automatiques (comme les satellites) ou les photos sans originalité (par exemple les photos des tabeaux d'un musée), ça m'a l'air plus compliqué. Pour les photos satellites par exemple, Google verrouille les conditions générales d'utilisation de leur site ou de leur application, ce qu'il fait qu'ils n'ont pas besoin de droit d'auteur pour empêcher la réutilisation.

En droit français, il semble établi que seuls les humains peuvent être des "auteurs" au sens du droit d'auteur. Donc pour les photos satellite, c'est pas gagné.

Tu confonds droit d'auteur, droit des marques, droit des modèles, droit des brevets, droits voisins, etc. Sans compter que le droit US (copyright) et le droit européen (droit d'auteur) sont assez différents sur le sujet. C'est un domaine complexe, et aucun d'entre nous n'en maitrise toutes les subtilités. Par contre, ça n'est pas très sympa de venir raconter un peu n'importe quoi quand on n'y connait rien.