Renault a écrit 7174 commentaires

Surtout qu'ici avoir ou non la porte dérobée revient à inclure ou non une version spécifique d'un logiciel.
C'est donc du hasard, parfois la distribution aura la bonne version parfois pas. On ne peut pas le prédire et aucune politique de distribution n'est bonne à cet égard. Donc en effet fanfaronner que X n'a pas la faille est ridicule dans ce contexte.

Là où la distribution peut jouer c'est en compilant et en intégrant le composant avec d'autres mesures de sortes que une faille ou une porte dérobée n'ait pas d'effets. C'est là où une distribution peut faire la différence à ce sujet, mais ce n'est pas ce qui nous intéresse ici.

Et je ne crois pas que la politique de Mageia soit justement très pro-sécurité. En même temps c'est un sujet complexe et même de grosses distributions avec plus de moyens peuvent faire mieux.

Ou pour la sécurité sociale.

Oui bien sûr, mais au delà de ça, des mises à jour classiques qui rendent le boot non fonctionnel chez Fedora sans que cela ne soit sous le contrôle de l'utilisateur car tout est allé au bout de la procédure, cela arrive, ce ne sont pas les rapports de bogues ou les questions sur le forum qui diront le contraire. Car il y a toujours des configurations logicielles et matérielles qui rendent ces étapes difficiles à garantir pour tout le monde, et avec suffisamment d'utilisateur il y en a toujours qui de temps en temps ont un pépin.

Donc avoir la possibilité de revenir à un état stable de manière immédiate c'est vraiment cool.

En moyenne c'est assez stable, mais des problèmes il y en a toujours. En particulier lors des mises à niveau.

Cela ne m'étonnerait pas que dans le futur on ajoute une couche de plus pour apporter la flexibilité manquante, avoir quelque chose du genre :

• Système minimal avec rpm-ostree : chargeur de démarrage, noyau, systemd, bibliothèques de base, environnement de bureau et écran de login (pas plus) ;
• Système classique pour installer des paquets en plus, plutôt orientés utilitaires ou outils bas niveaux pour le développement ou les systèmes qui à priori ne compromettent pas le boot et pour qui l'isolation ne fonctionne pas bien ;
• Flatpak pour les applications graphiques ;
• Conteneurs avec toolbox pour ceux qui veulent des environnements de développement plus flexibles que ce qui est proposé par Fedora, notamment concernant les versions des langages de programmations et des outils associés.

Cela serait cohérent avec la conception derrière et dans la continuité de Fedora.next en un sens. Si jamais du moins aucune solution satisfaisante n'est trouvée autrement.

Pour un truc comme Copilot, il faut donc prouver que le code issu du logiciel est dérivé d'un bout de code de la base de données.

Même pas dans la BDD.

Copilot reproduit par accident un bout de code identique qui n'était pas dans son apprentissage, cela violerait la loi. De la même façon que si par hasard Midjourney reproduit une oeuvre de pop culture sans pour autant l'avoir dans son entrainement aurait le même problème. C'est peu probable, mais ça montre qu'on n'a pas besoin d'avoir les données d'apprentissage pour faire condamner. Le fait que ce soit dans l'apprentissage ou non pourrait influer probablement la sanction mais ne change pas la violation de la loi.

Ça me semble impossible avec un LLM correctement paramétré.

Je te trouve bien confiant sur ce point quand on voit justement ce que tous les LLM font à ce sujet jusqu'à aujourd'hui. En dehors de supprimer toute référence lors de l'apprentissage c'est difficile à éviter en tout cas à ce jour.

Encore une fois, la propriété intellectuelle ne se dilue pas, la contrefaçon est binaire : 1% de contrefaçon, ça n'existe pas; il existe un seuil de divergence au-delà duquel l'auteur initial n'a plus de droits à faire valoir.

Si si.
Prends une image couverte par le droit d'auteur, prends en 50% à l'identique ou presque et change le reste. Tu tomberas sous le coup de la loi même si 50% est de toi. De même pour un morceau de films, livres, musique, etc.

Le code n'est pas différent, si tu prends quelques fonctions non triviales directement d'ailleurs, tu peux avoir des problèmes même si le reste de ton code est fait maison.

Au passage, il y a aussi une bizarrerie à résoudre : dans oeuvre dérivée, il y a "oeuvre". Or, il est admis que la sortie d'un LLM n'ouvre pas de droits d'auteurs parce que ça n'est pas une oeuvre de l'esprit. Il n'y a donc pas d'appropriation des droits d'auteurs par quiconque.

Il n'y a pas besoin, cela n'autorise pas les LLM à générer tout ce qu'ils veulent et on le voit bien avec les affaires en cours.

Cela ne veut rien dire ;)

Ils utilisent sans doute une techno qui permet de coder l'application mobile et son versant web avec un minimum de duplication. Ce genre d'outils ne génère pas un code HTML particulièrement léger.

Beaucoup de politiques sont des brutes en économie,

Certains, probablement, beaucoup ça reste à démontrer.

C'est le point principal et je pense que cela passera. Si c'est possible de le faire en fair use toute la culture incluse dans les IA sera anglo-saxonne.

Le fair use pour s'entrainer c'est une chose, le fair use dans le résultat c'est beaucoup moins probable et ça va être un peu le nerf de la guerre.

Si les IA débitent facilement des œuvres contrefaites cela peut poser un problème dans le cas où la justice considère que l'entreprise doit mettre en place des mesures sous peine de sanctions. Et ce n'est pas un sujet trivial. Cela pourrait totalement mettre à mal le fonctionnement de ces IA justement.

C'est donc à voir, la justice va se pencher dessus mais j'ai de gros doute que ça passera crème sans efforts de la part des entreprises concernées.

Les violations de copyright c'est pas vraiment dépendant du moyen technique utilisé pour fabriquer l'œuvre je crois.

Oui.

Je pense que si tu reproduit à l'identique une grande part d'un code il y a de toute façon question à se poser, ça n'a aucune chance de se produire au hasard hors de toutes petites portions.

C'est l'idée oui.

Après si tu donnes un prompt assez précis pour que ça se reproduise, on peut soupçonner que le prompt avait pour but de reproduire l’œuvre …

Pas besoin, il y a eu des cas où des termes pourtant vagues et génériques permettait de ressortir des visuels de la pop culture. On peut imaginer le cas où tu demandes un générateur de labyrinthe et il te ressort un code proche (voire identique) à un code existant.

Et puis pour démontrer que le modèle est bel et bien généré par le jeu d'apprentissage prétendu ça doit pas être si simple, faut un apprentissage qui soit reproductible, c'est un challenge https://neptune.ai/blog/how-to-solve-reproducibility-in-ml Pas dit que ce soit la priorité des industriels d'avoir une reproductibilité digne d'une science ouverte et reproductible, c'est pas leur objectif numéro 1.

Ici pas besoin, si quelqu'un identifie une correspondance, il y a violation. Pas besoin de prouver que c'était dans le jeu d'apprentissage. Après à l'entreprise de dire si c'était présent ou non dans l'apprentissage, on peut supposer que la justice ne traite pas les cas de manière identique.

Ce qui est sûr c'est que si le modèle recrache tel quel du contenu sous copyright, alors il y a violation de droit d'auteur même si la phase d'entrainement est valide juridiquement (en admettant qu'elle le soit).

C'est une grosse limitation pour ces outils qui vont devoir y mettre des moyens de dingue pour s'assurer qu'ils ne violent pas le droit d'auteur dans ces conditions. Le plus simple est effectivement de limiter les données d'entrainement à ce qui est permis, cela limite les risques et en cas de coïncidence (sortir un code protégé mais qui n'est pas dans les données d'entrainement) ils pourraient démontrer que c'est une coïncidence et non une violation de copyright.

Euh tu sais que la configuration de NetworkManager que tu l'édites à la main, que tu utilises la GUI de GNOME ou nmcli cela revient au même ? Les fichiers sont stockés au même endroit et de la même façon, la conf est identique… Et heureusement, ce ne sont que des interfaces utilisateurs différents, le reste de l'outil est le même.

Notons que la TV en direct utilise du multicast pour être distribué sur le territoire national. C'est bien moins coûteux et gourmand que des flux individuels pour la même qualité d'image.

Écrire un algo en pseudo code ne me semble pas très pertinent dans un cadre pro. Dans un contexte scolaire je pense que ça peut avoir du sens car tu apprends.

Par contre faire la conception sur papier, poser les idées, passer du temps à réfléchir dessus, etc. cela a du sens dans un contexte pro. Après chacun son outil mais je trouve la papier pratique pour cela.

Je trouve, oui. En quoi ça ne serait pas pertinent selon toi ?

Je veux dire, tout le monde ne connaît pas le sujet, l'article est assez trompeur sur les capacités (je trouve), le manque de recul sur l'IA est assez important en ce moment dans l'esprit de beaucoup de gens, rappeler concrètement les limites ne me paraît pas inutile.

Peut être, cela n'est cependant pas trivial et ne peut être déduit avec ce qui a été publié.

Mon propos n'est pas de dire que l'approche ne mènera à rien dans tous les cas. Je dis juste que ce qui est présenté pour l'instant ne montre rien de si extraordinaire pour justifier un article aussi dithyrambique.

C'est une preuve de concept, faut creuser la question et pourquoi pas, ça peut donner des résultats intéressants (ou pas).

C'est un peu comme lire les articles scientifiques de certains présentant des nouveaux matériaux ou traitements médicaux révolutionnaires alors qu'en vrai la plupart n'iront pas plus loin que le labo où la découverte a été publié car finalement c'était une mauvaise piste. Ce n'est pas un mal de communiquer dessus mais je trouve la forme souvent excessive.

Après c'est Korben, ce n'est pas la première fois qu'il fait ça et typiquement je ne le lis pas pour cette raison.

Le seul ajout est celui de tests automatiques mais le taux d'échecs même dans un cas simple est encore très faible.

Et encore très élevé, pardon.

Perso je suis moyennement convaincu, l'article de Korben semble très pute à clic.

Ce n'est pas inintéressant mais franchement limité à ce stade. De ce qu'on peut en lire (car honnêtement je ne trouve pas que le dépôt apporte beaucoup d'infos sur l'entrainement et les tests). Cela semble travailler sur des fonctions apparemment isolées et relativement triviales (en tout cas, pas d'exemples montrant le contraire), le résultat est déjà obtenu par des outils plus classiques (décompiler du binaire en instruction C avec peu de valeur ajoutée n'a rien d'extraordinairement difficile). Le seul ajout est celui de tests automatiques mais le taux d'échecs même dans un cas simple est encore très faible.

Alors oui, c'est le début, mais c'est encore la partie simple : le modèle arrivera-t-il à fonctionner sur un programme entier à apporter de la valeur ajoutée comme ça ? Pas sûr non plus. Ce n'est en tout cas pas à ce stade une révolution mais plus une preuve de concept à creuser.

Ce raisonnement dépend de la structure de l'empreinte des coûts environnementaux comme financiers.

Une infrastructure télécom ce sont beaucoup de coûts fixes, c'est même l'essentiel du prix de la facture. Que tu consommes ou pas tes données, le coût financier et environnemental sera proche. Car il faut maintenir l'infrastructure, les antennes relais, les bornes de distributions, les serveurs, etc.

D'ailleurs cela se voit bien, quand des offres illimités sont apparus, ils étaient rarement dans les prix haut de gammes des forfaits limités de l'époque. Et aujourd'hui un forfait à 100 Gio en France pour mobile est significativement moins cher que pour la plupart des pays voisin avec des quotas pourtant bien plus bas.

Pour l'illimité au moins tu ne te poses pas la question, ce mois ci tu consommes plus pour X ou Y raison, aucun problème. Cela a aussi un coût mental de se préoccuper de savoir si on a de quoi tenir le mois, s'il faut acheter plus de data exceptionnellement, si on doit réduire significativement son usage car on ne veut pas payer plus, etc.

Ça peut, poruquoi pas.

Bah non, si du moins l'outil qui parse ces déclarations n'en est pas une.

Ce qui est pertinent c'est de considérer la conception et maintenance plus que l'exécution, une IA reste un programme comme un autre à la fin, la différence se situe en amont lors de son élaboration.

La conception fait que l'algo exécutée par l'IA n'est à priori pas connu dans le détail par ses concepteurs et utilisateurs (sinon autant écrire l'algo directement à la main, c'est plus fiable et efficace). L'algo est élaborée de manière dynamique en fonction de comment il a été entrainé et des tâches qu'il doit mener.

Cela rend aussi la maintenance délicate, difficile d'apporter des garanties fortes de fonctionnement car le détail de l'algo n'est pas connu, et corriger des défauts à la main est difficile (un peu comme altérer un binaire sans le code source, c'est faisable mais délicat). Il faut probablement ajouter des éléments lors de la conception et entrainement en croisant les doigts que cela règle le problème sans en introduire d'autres.

Le HTML ou autres type de documents déclaratifs ne sont pas forcément de la programmation d'une part, et d'autres part le moteur de rendu est un algo conçu et éditable à la main.

Une personne centenaire peut partager le même numéro de sécurité sociale qu'une personne récemment née.
Cela pourrait arriver aussi si un département a beaucoup trop de naissance le même jour (je doute que ce soit déjà arrivé et si cela risque d'arriver).

C'est improbable mais pas impossible.

Si tu demande à brûle pourpoint un avis à ChatGPT sur un sujet plus ou moins lié à la politique, il n'est jamais catégorique (hors hallucinations possible, mais ça ne m'a pas l'air d'être le cas).

J'ai vu assez d'exemples qui montraient qu'il était capable de tout, surtout suivant comment tu le prépares.
C'est tout le problème de ces systèmes, avoir des garanties de fonctionnement est difficile (si ce n'est impossible).

Oui, c'est bien pour ça que j'écarte cette hypothèse.

Ce n'était pas clair si tu l'écartais pour cette raison ou parce que tu souhaitais plutôt évaluer les autres hypothèses.

Evidemment. Par contre, c'est l'absence de nuances dans la réponse que m'interroge.

Des réponses non nuancées des LLM ce n'est pas le plus dur à obtenir à priori. Et c'est d'ailleurs une partie du problème.

J'ai pas l'impression que tu ais compris le sens de mes propos.

Honnêtement tes interrogations semblaient plus génériques que cela donc effectivement je n'avais pas compris où tu voulais en venir.

J'ai sans doute un biais à analyser ta réponse ainsi car des gens qui utilisent des LLM pour tout et n'importe quoi sans recul bah j'en croise un peu trop et je trouve cela problématique à plus d'un titre. Donc mes excuses pour ce biais d'interprétation.

Je trouve la réponse de ChatGPT assez étonnante, généralement les llms ne sont pas aussi catégorique

Tu trouves ?

ont souvent des réponses de type thèse / antithèse / synthèse ou avantage / inconvénient / résumé.

Tout dépend du prompt et du sujet, tu as de tout.

Si on écarte l'idée d'une déduction logique de la part du modèle

Un LLM ne fait pas vraiment de déduction logique de ce style.

Un biais induit par les développeurs dans les données d'apprentissage sur ce sujet.

Il me semble assez improbable de croire que des données d'entrainement soit sans biais tout court. Il y a forcément une sélection et un biais introduit à cette étape même si ce n'est pas conscient.

J'espère que c'est la deuxième hypothèse parce que dans le cas contraire on est vraiment dans la merde

Perso je pense surtout qu'il faut se rappeler des limites de ces technos et d'arrêter de les utiliser comme si elles n'en avaient pas. Cela peut rendre des services mais il faut avoir un regard critique quant aux réponses données.

Oui Red Hat a soutenu CentOS longtemps (si ce n’est de tout temps) financièrement et « humainement », mais en laissant toute liberté à CentOS. Red Hat a acquis CentOS (la marque) et embauché le board de CentOS en 2014 seulement.

Cela fait quand même 10 ans, c'est énorme.

Elle était 100% identique au niveau du code source open-source et uniquement à ce niveau.

Cela se discute que c'était 100% identique, mais je vais revenir après là dessus.

Quant au fait que tu trouves ma formulation imparfaite, ambigu voire fallacieuse. Merci d’expliquer en quoi. Tu n’as fait que répondre à côté de la plaque pour défendre Red Hat là. Pour moi comme pour beaucoup un « rebuild » n’est pas un dérivé.

Un rebuild est par définition un dérivé car ce n'est pas une copie parfaite, je vais l'expliquer en quoi.
Par ailleurs tu viens de le dire enfin que pour toi un rebuild n'est pas un dérivé de ton point de vue. Ce n'était pas explicité dans tes précédents messages donc oui c'était cryptique comme point de vue sans ce rappel de vocabulaire (de ton point de vue car personnellement je ne suis pas d'accord).

Tu n’as clairement pas compris mon message. Ce que je reproche à Red Hat c’est d’avoir saboté « CentOS » (ie: CentOS tout court) en réutilisant le nom pour une distribution qui n’a plus rien à voir, mais fondamentalement plus rien à voir, en terme d’architecture et de destinations. Ils auraient pu créer un nouveau nom, un nouveau logo. Et s’ils ont réutilisé "CentOS" c’est clairement pour sa réputation et uniquement pour cela. Ils ne pouvaient ignorer la confusion.

Honnêtement des produits ou marques qui évoluent dans leur cibles ou caractéristiques principales tout en gardant le même nom pour des raisons commerciales ça arrive tous les jours. Que Red Hat le fasse ne me choque pas le moins du monde car honnêtement je m'en fou, c'est du détail. Que CentOS Stream s'appelle CentOS Stream ou Red Hat Community edition ou quoique ce soit d'autre ne change pas la réalité derrière le produit.

Et c'est pareil pour tout, si demain Debian Sid devient la version stable de Debian après tout leur historique, je ne vais rien dire non plus. Ou si demain Debian devient une rolling release aussi en gardant le même nom.

Mais bon, je pense que tu n’as pas bien compris la différence, si déjà tu ne vois pas l’intérêt d’une distribution « 100 % identique » (au niveau du code source, et seulement pour la partie opensource de celui-ci), tu es l’exemple parfait qu’ils ont « bien » fait de se permettre cette manipulation honteuse, car sa grossièreté ne saute manifestement pas aux yeux de tout le monde.

Revenons sur le compatible bug pour bug.
Pour moi c'est une promesse qui n'a jamais existé et n'existera probablement jamais. On s'en approche le mieux possible évidemment, mais l'atteindre de manière absolue pas vraiment. EN partant de ce principe là et par le modèle choisi, en réalité CentOS Stream est très similaire à ce qu'était CentOS de ce côté là, juste qu'au lieu d'être en retard avec RHEL il est en avance de phase.

Pourquoi le bug pour bug est une chimère ?

Déjà car il y a des mises à jour en continue dans RHEL et que chaque mise à jour introduit des changements (sinon ça n'aurait aucun intérêt). Par définition CentOS avait du retard, souvent de quelques jours voire plus. Il n'y a aucun jour X où le code de RHEL et CentOS étaient identiques. Et comme les flux de traitements sont différents, même en admettant qu'un lag réduit, RHEL pouvait publier 2 maj avec des jours d'écart quand CentOS va les proposer en même temps. Donc tu auras par exemple dans la nature des RHEL avec une de ces maj installées et pas l'être quand sur CentOS cette situation n'arrivera pas.

En plus les RHEL et CentOS ayant un système d'image traditionnelle ne sont jamais identiques entre elles, l'ordre des mises à jour n'est pas identique d'un site à l'autre même en suivant les mêmes instructions en même temps ce qui est source de bogues et de comportements différents.

Ce n'est pas pour rien que Red Hat investit la question des images à base de rpm-ostree et qu'il y a une "hype" pour les images immuables car ce sont les seuls moyens d'apporter la garantie que tu recherches. Sans cela, tu ne garanties rien pas plus qu'AlmaLinux ne le fait. Tu t'en approches mais c'est tout. De même pour la compilation reproductible même si cela n'est pas suffisant non plus, CentOS et RHEL n'ont jamais été été compatibles à ce sujet.

Et l'un dans l'autre la garantie apportée par CentOS Stream à cet égard n'est pas si différente que ce que faisait CentOS dans le passé. Mais dans l'autre sens.

Et rendait pas mal de services aussi.

Mais CentOS Stream aussi rend pas mal de services et est exploitable en production.

Sinon ALMA Linux et Rocky Linux n’auraient pas été créés pour remplacer CentOS dès que la décision de Red Hat a été connue.

Mais je ne condamne pas ces projets moi. Ils le font s'ils le veulent, on verra s'ils tiennent dans la durée, c'est tout ce que je leur souhaite mais l'histoire montre que c'est délicat.

C'est l'avantage du Logiciel Libre à cet égard par ailleurs. Et Red Hat est tout aussi libre d'arrêter de faire CentOS comme avant.

Tu sais qui a lancé le projet Rocky Linux ? Si tu ne sais pas renseigne toi

Merci je pense que je connais bien le dossier.
Et donc ? Perso je m'en fou un peu des noms, des problèmes d'égos, des gens qui font n'importe quoi ou qui étaient une référence un jour X pour faire n'importe quoi le lendemain ce n'est pas ce qui manque pour qu'on ne considère pas les arguments d'autorité.

Je pense que j'ai assez expliqué et justifié mon point de vue.

ça t’incitera peut-être à ôter les œillères qui font que tu ne vois rien à redire à la réutilisation du nom pour la nouvelle distribution de l’écosystème Red Hat (ie: CentOS Stream), bien que parfaitement légale, est foncièrement malhonnête intellectuellement parlant.

Ce serait bien d'éviter les attaques personnelles, je ne partage pas ton point de vue ne signifie pas que je suis aveuglé, con ou quoique ce soit d'autres.

Sinon tu t'attaches à une considération marketing, c'est ton droit, moi je m'en fou, c'est mon droit aussi.
Car fondamentalement, si CentOS Stream se nommait je ne sais pas Open Red Hat Community Edition, tout en arrêtant CentOS par ailleurs. Ton discours serait différent ? Étant donné ton propos j'en doute. Et s'il était différent, ce serait de tout façon peu cohérent.

Et Alma Linux comme Rocky Linux auraient été lancés aussi.

Bref, ça n'aurait fondamentalement rien changé je pense et cela ne devrait pas de toute manière car ce n'est qu'un nom. Cela ne change pas les propriétés de chaque entité.

Tu dis sûrement vrai, ce serait juste afin de connaître la valeur réel du facteur pifométrique « parfois plusieurs » que tu emploies, ainsi que quelques exemple des problèmes ayant, comme tu le suggères, eu lieu et auxquels tu fais allusion.

RHEL 6 sorti le 10 novembre 2010, CentOS sorti le 27 novembre 2011 (plus d'un an !)
RHEL 7 sorti le 10 juin 2014, CentOS 7 est sorti le 7 juillet 2014 (presque un mois)
RHEL 8 sorti le 7 mai 2019, CentOS 8 le 24 septembre 2019 (donc 4 mois après)

Bref, pour les mises à jour majeur, on voit bien un écart en moyenne de plusieurs mois.

Pour les sorties intermédiaires (donc par exemple 6.1) la page de Wikipédia anglaise fait le listing avec les délais pour chaque version :https://en.wikipedia.org/wiki/CentOS

En général il y a toujours au moins 2 semaines d'écart, et souvent 1 mois et parfois plus. Tes 2-3 jours n'ont jamais existé en vrai.

Cela te convient ? Oui, je pense comprendre le dossier en question.

Par ailleurs compiler une distribution c'est un peu mon boulot quotidien via Yocto pour différents clients, je suis également de près les arcanes de Fedora, cela m'aide à comprendre à quel point des problèmes peuvent survenir à tous les étages et la difficulté de la tâche dont de la reproduction de la compilation.

Cela signifiait que sans licence Red Hat, pas moyen de tester la version en développement pour s'assurer que son parc ou son application sera compatible car c'était un développement en mode fermé.
Tout à fait. Ça permettait « juste » de tester ses applications avec n’importe qu’elle version stable, publiée, de RHEL sans devoir acquérir une ou plusieurs licences ! Sérieusement, tu me sidères…
Ce que tu dis sur l’utilité d’avoir une distribution comme CentOS Stream est tout à fait juste également. Mais je crois sincèrement que tu ne vois pas à quoi servait une distribution comme CentOS, qui est exactement les mêmes usages qu’ALMA Linux ou Rocky Linux aujourd’hui.

Mais tu déformes totalement mon propos depuis le début.
Je ne dis pas que c'était le seul intérêt de CentOS, mais que ça en était une et avec un retard tel que c'était bloquant dans cette tâche (et pénalisait Red Hat par ailleurs).

Je ne dis pas que Alma Linux ou Rocky ne servent à rien et qu'il faut aussi les brûler en enfer. Ils existent, tant mieux, le libre est là pour ça. Mais je signe et persiste, pour beaucoup d'utilisateurs CentOS Stream fait le même job que CentOS et est en fait plus intéressant d'un point de vue écosystème et communautaire que ne l'était CentOS.

Tu peux ne pas être d'accord si tu veux, je pense avoir justifié mon point de vue qui ne me semble pas mauvaise justement.