Tu décris une méthode qui ressemble beaucoup au cycle en V traditionnel.
Il y a beaucoup de gens qui ne travaillent pas comme ça, mais avec des méthodes dites "agiles" ou ces étapes ne sont pas du tout découpées de la même façon.
En ce qui me concerne, l'écriture de code n'est pas seulement pour dire à la machine ce qu'elle doit faire. Il s'agit d'une méthode de formalisation des besoins exprimés. Cette formalisation dans un langage strict et structuré fait que on se rend compte, lors de l'écriture du code, qu'il y a des cas non prévus dans la spécification, voire des informations contradictoires. Cela permet aussi de se poser la question des bonnes structures de données à adopter pour faire le traitement de façon efficace.
Il y a donc constamment des allers-retours entre l'écriture du code et la rédaction de la spécification.
Je ne suis pas capable de faire ce travail en exprimant les choses en langage naturel (français ou anglais). Je ne pense pas que la personne qui rédige la spécification pourrait remplacer mon travail par l'utilisation d'un LLM. Je ne pense même pas qu'elle pourrait réduire mon travail: si une partie du code était générée par un LLM, ça me ferait d'autant plus de code à relire et à comprendre. Pour moi cela demande plus d'effort de lire et comprendre le code de quelqu'un d'autre, que d'écrire moi-même du code. De plus, le processus mis en place (écriture par une personne et relecture par une autre) est un moyen supplémentaire de détecter les divergences avec la spécification et les oublis. Lors de l'utilisation d'un LLM, c'est la première chose qui va sauter: le développeur ayant demandé au LLM de générer le code, ne l'a pas écrit, mais il l'a relu. Il va donc penser qu'une deuxième relecture n'est pas utile.
Il y a des cas où le code n'est pas critique, suffisamment simple, et où ça peut marcher. Mais dans ce cas, je ne vois pas l'intérêt d'en faire un journal sur linuxfr, car on apprendra rien de nouveau.
22 ans de moulage sur Linuxfr et ce serait un contributeur débutant? Je n'y crois pas…
C'est pas compliqué: les personnes qui n'ont ni fait l'effort d'écrire leur propre code, ni fait l'effort d'écrire peur propre journal, personne n'a envie de lire le résultat (ni le code, ni le journal). Si iels veulent des commentaires positifs et encourageants, après tout, ils peuvent en demander à leur LLM préféré qui saura faire ça très bien. Pourquoi embêter des humains pour ça? Il faut pousser la démarche jusqu'au bout, remplacer les développeurs, mais aussi les utilisateurs et les détracteurs du projet par des LLM. Ainsi les gens pourront enfin cesser de passer du temps devant leur ordinateur, pourront sortir prendre le soleil, et le monde sera meilleur.
Comme je l'ai écrit, la réponse aux questions dépend beaucoup du projet et aussi des raisons pour lesquelles on souhaite (ou pas) rejeter l'utilisation de LLMs.
Si les raisons sont une inquiétude sur la qualité du code ou des rapports de sécurité (avec un rapport qualité/volume produit), alors, effectivement, on peut limiter le problème d'autres façons (en disant simplement qu'on rejette les contributions de mauvaise qualité, peu importe comment elles sont faites).
Ça soulève d'autres questions. Je reprend les cas que je connaît. Dans Haiku, on reçoit souvent des contributions (faites à la main) qui ne vont pas au bout des choses. On aide les gens à mieux comprendre l'architecture, à améliorer leur proposition s'ils en ont envie, ou bien on reprend le truc en main et on finalise ou on réécrit les changements. Ce faisant, on a en tant que relecteur la satisfaction d'aider quelqu'un à monter en compétence, et les gens qui envoient des patchs en profitent pour apprendre des choses (clairement sans Haiku je n'aurais jamais acquis autant de connaissances sur le fonctionnement des systèmes UNIX, la programmation en C++, la conception d'IHM, …).
Dans ce contexte on a même réussi à encadrer des contributeurs âgés de 13 à 17 ans dans le cadre du Google Code-In. Niveau qualité du code produit, il est clair qu'un LLM aujourd'hui est loin devant ce qu'on peut attendre d'un adolescent de 13 ans. Cependant, nous avons pu faire fonctionner ce mode de contribution assez spécial, en particulier parce que nous avons produit une liste de tâches très détaillée et aussi parce que nous avons recruté les participants d'une année pour aider à encadrer ceux de l'année suivante.
Je ne pense pas que on puisse avoir une telle qualité d'échanges humains si on reçoit des masses de contributions générées par LLM. Dans le cas de Haiku encore, c'est déjà difficile sans LLM de répondre à toutes les demandes de revue de code. Et il n'est pas question ici de mettre en place un système de "réponse automatique" par LLM (on l'a fait par contre sur les aspects qui sont automatisables, comme le formatage du code, et il faudrait développer ou mettre en place d'autres outils par exemple pour le respect des conventions de nommage).
Voilà pour le cas où l'argument est sur la qualité et le volume des contributions. Ça dépend du volume de contributions reçu, de l'intérêt que les développeurs ont pour le partage de compétence via la revue de code, de la disponibilité des contributeurs. Pour des exemples de projets qui font des choix très différents parce qu'ils ont des contraintes différentes, citons sqlite (c'est impossible de leur faire accepter un patch, ils préfèrent réécrire le code eux-mêmes), ou Linux (très gros volume de contribution, ne peut pas trop se permettre d'avoir des failles de sécurité, pas assez de gens pour traiter toutes les contributions reçues: l'utilisation de LLM peut être une bonne solution une fois qu'on en est là).
Ensuite il y a l'argument du copyright. Là je peux citer Ryan Gordon qui travaille sur SDL. Lorsqu'il reçoit un patch généré par LLM, son souci principal est que cela pourrait être recopié de code source existant par ailleurs dans les données d'entraînement du LLM utilisé et sans en citer l'auteur. Devant l'incertitude au niveau de la license, l'option qu'il retient est de réécrire le code de façon différente (ce aui est d'autant plus difficile que le patch est simple). On a fait ce genre de choses chez Haiku aussi: une personne a vibe codé un tas de modifications (autour de la gestion de l'USB et des périphériques MIDI en particulier), un développeur de Haiku a regardé les changements et réécrit des correctifs de sa propre main. Là aussi, les enjeux ne sont pas les mêmes selon le projet. J'ai travaillé dans des entreprises où le risque de contamination du code interne par de la GPL faisait vraiment très peur aux juristes (de façon justifiée ou pas). Il y a d'autres projets où c'est beaucoup plus détendu là dessus (par exemple Linux qui n'est pas connu pour insister très fortement sur le respect de la GPL).
Enfin il y a l'argument des conséquences écologiques et en utilisation de ressources. Et là aussi le compromis change selon, disons les orientations politiques et éthiques du projet. Peut-être qu'on en a rien à faire. Peut-être que la fin justifie les moyens. Ou peut-être que c'est un projet très orienté sur la réduction des ressources et l'informatique frugale, auquel cas, le choix d'utiliser massivement des LLM serait discutable. Il n'y a pas une seule réponse et ça n'a pas forcément à être 100% oui ou non. De la même façon que plein de gens sont écologistes mais prennent quand même l'avion pour partir en vacances parce que "ça change rien, l'avion décollera peu importe si je suis dedans ou pas". Bon courage pour calculer le bilan carbone précis de chaque contribution, et savoir si oui ou non, le résultat net est positif. Je ne pense pas que ça soit faisable, et donc, la solution est forcément une décision arbitraire, qui peut être très simple (pas d'IA, ou full open bar) ou plus nuancée, ou décidée au cas par cas selon l'humeur du moment.
Pour en revenir au cas pratique de Haiku: la raison officielle qui conduit à interdire l'utilisation de LLMs, ce sont les problèmes de copyright. Dans ce contexte, il n'y a pas de problème si quelqu'un fournit un cas de test généré par un LLM (il servira à tester la correction mais ne sera pas intégré dans le code source), ou si quelqu'un fournit une contribution contenant du code généré par LLM (elle ne sera pas intégrée mais elle pourra servir de référence pour refaire une implémentation indépendante). Bien sûr cette approche n'a aucun sens si l'argument retenu était celui de la consommation de ressources (on fait 2 fois le travail: de ce point de vue c'est donc moins bien); et il n'a aucun sens non plus du point de vue de la qualité des contributions et de la montée en compétence des contributeurs (on passe du temps à réécrire du code qui existe déjà, on ne crédite pas directement les gens ayant utilisé le LLM comme auteurs des changements mais seulement comme ayant identifié le problème).
Il y a encore d'autres raisons pour exclure les LLMs que j'ai entendues, mais sur lesquelles j'ai moins réfléchi. Par exemple, le fait que les LLMs sont peut-être vraiment conscients, et que c'est donc une forme d'esclavage ou d'exploitation animale de les utiliser; ou encore des raisons religieuses, dans certaines religions, tenter de recréer l'intelligence humaine qui est l'aboutissement du travail de Dieu, c'est mal vu (je résume n'importe comment parce que je suis totalement incompétent dans ce domaine). Je suppose que cela amènerait encore des réponses différentes.
J'ai un avis sur la question, mais je vais le formuler sous forme de auestions pour que chacun puisse prendre sa propre décision pour ses propres projets (et la réponse n'est pas forcément la même dans tous les cas, par exemple en ce qui me concerne, l'approche de la sécurité dans Haiku n'est pas la même que dans mon emploi salarié, ou que dans d'autres projets que je maintiens):
Est-ce que trouver des failles de sécurité justifie l'impact écologique des LLMs lancés à toute vapeur pour faire une recherche par force brute de vulnérabilités?
Est-ce que la charge de travail est bien gérée, c'est à dire que les gens qui ont lancé le LLM prennent le temps d'analyser ce qu'ils ont trouvé et de faire une explication claire, une vraie analyse d'impact et une proposition de correction, ou bien est-ce qu'il s'agit de noyer les développeurs de logiciels libres sous des rapports dont la majorité ne sont pas des failles exploitables, et les laisser se débrouiller avec ça?
Ce sont des questions qui se posaient déjà avant l'arrivée de l'IA. Dans Haiku par exemple on s'attend à ce que les contributeurs fasse un peu d'efforts pour formater leur code correctement selon nos règles (certaines personnes refusent de le faire et considèrent que c'est une perte de temps), le tester avant de nous l'envoyer (on reçoit régulièrement des propositions de changements qui ne compilent même pas), répondre aux questions des développeurs sans s'énerver, parfois devoir faire du refactoring pour rendre une solution plus générale plutôt que un patch contournant le problème, etc. C'est assez exigeant, mais le but est que les gens qui commencent à participer à Haiku par de petites contributions s'impliquent de plus en plus et que leur travail nécessite de moins en moins de revue pour être intégré.
Lorsque la contribution externe est générée par LLM, le rapport de force change beaucoup. Il y a alors deux options faciles: interdire les LLM pour tout le monde, ou utiliser soi-même des LLM pour tenter de rééquilibrer. Il y a plein d'options moins faciles: accepter le déséquilibre, interdire toutes les contributions externes, …
C'est un peu comme si une entreprise avait un serveur email implémentant SMTP légèrement différent, empêchant les emails de s'échanger avec d'autres serveurs, mais que comme c'était une multi-nationale avec beaucoup de clients, on considérait que c'est aux autres de changer. Fort heureusement, les emails étaient déjà trop répandus et il y avait déjà beaucoup de gros fournisseurs, donc même avec sa puissance, Google n'a pas pu faire de même avec GMail.
Du côté des serveurs je ne sais pas, mais du côté des clients, l'implémentation IMAP de Google fait des choix assez inhabituels, et la mauvaise intégration avec les clients "lourds" existants a conduit pas mal de monde à oublier l'existence de Thunderbird et de ses concurrents pour utiliser exclusivement le webmail.
Il se passe aussi un peu la même chose avec le web: Google n'a pas réussi à imposer ses spécifications au W3C (qui a un fonctionnement à peu près aussi lourd que celui de la XSF) et donc cela a abouti à la création d'un organisme de standardisation concurrent, le WhatWG, avec la spécification de HTML5 et de plein d'autres trucs dont certains abandonnés entretemps (QUIC, SDCH, SPDY, HTTP 2, HTTP 3, …).
On peut donc imaginer ce qu'il se serait passé si la XSF avait accepté telle quelle la spécification de Google:
Google pose sa spec sur la table
La XSF accepte sans réfléchir
D'autres clients essaient d'implémenter la spec
Google ou les implémenteurs d'autres clients se rendent compte que la spec est incomplète, mal fichue, etc
Google ou les autres implémenteurs décident finalement de corriger la spécification de façon incompatible avec l'original
Certains clients implémentent l'ancienne spec, d'autres la nouvelle
Pas d'interopérabilité entre les différents protocoles
"ouin ouin XMPP c'est nul il y a des problèmes de compatibilité entre clients"
Bref, Google a fait un truc fonctionnant avec une seule implémentation de client et une seule implémentation de serveur. C'est beaucoup plus facile de faire ça que de faire une spécification interopérable pour un protocole standardisé. Ils n'avaient aucun intérêt à faire l'autre moitié du travail, ni à attendre que ça soit fait avant de déployer leur client. Je ne vois pas bien ce que la XSF aurait pu faire pour changer ça.
Apple said that iPhone 18 Pro Max devices that have been affected by this cellular issue on the AT&T network cannot have service reactivated with a software update. Instead, Apple said the device must be replaced entirely
Apple did not disclose the underlying cause of the issue.
Et ben j'aurais bien aimé avoir plus de détail sur ce bug qui n'est pas réparable et nécessite carrément de changer le téléphone. Suppositions possibles (mais il y en a sûrement plein d'autres):
Le modem envoie n'importe quoi et se fait bannir du réseau de AT&T
Destruction matérielle ou logicielle du modem (firmware corrompu, données essentielles effacées, mauvaise configuration qui endommage l'émetteur radio?)
Le logiciel du téléphone envoie des commandes invalides au modem qui finit par se mettre dans un mode de sécurité non déverrouillable.
Il me semble que seule la "marketplace" (ce qu'il restait de PriceMinister suite à son rachat par Rakuten) est concernée par cette fermeture. Victime de la concurrence d'Amazon, leboncoin, wish, temu, aliexpress, … mais peut-être aussi du renommage en "Rakuten marketplace" alors que le nom de PriceMinister était assez connu à l'époque.
Je ne vois pas le rapport entre le défaut de couvercle de l'EPR de Flamanville (qui n'a pas subi d'incident, seulement un remplacement préventif au bout de 2 ans pour une pièce risquant de vieillir prématurément à cause d'un défaut de fabrication constaté bien avant qu'il y aie un problème - pas d'un défaut de conception) et la centrale de Fukushima. Du coup je ne suis pas bien le raisonnement.
Quant aux cygnes noirs, y
leur population est estimée entre 300000 et 500000 individus. Ils sont donc moins rares que d'autres espèces d'oiseaux menacées, et beaucoup plus facile à trouver que les accidents nucléaires.
Dans le cas de l'EPR: il y a eu une erreur qui a conduit à une pièce non conforme au cahier des charges (pourcentage de carbone plus élevé que ce qui était demandé).
Donc je comprend pas le commentaire. Le cahier des charges demandait un truc, la pièce produite ne répondait pas à ce qui était demandé. Ensuite se pose la question "est-ce que c'est grave" et dans ce cas la réponse est: pour le fond de cuve, non, parce qu'on peut surveiller sa dégradation et intervenir lorsque ce sera nécessaire. Pour le couvercle, oui un peu, parce que on ne peut pas l'inspecter aussi facilement. Cependant, la conséquence est seulement un vieillissement accéléré, ça ne mettait pas en danger le fonctionnement de la centrale pendant les 30 mois d'essai.
Donc, mise en place d'un plan pour remplacer la pièce défectueuse au moment opportun sans retarder encore la mise en service et sans prendre de risque inutile.
La méthode me semble plutôt la bonne, précisément celle qui fait que on aboutit pas à une désintégration de navette, un déraillement de TGV, ou une implosion de sous-marin.
La transparence sur les problèmes fait par contre que tout le monde est au courant du moindre souci, ce qui donne l'impression qu'il y a tout le temps des problèmes.
Je sais pas comment ça se passe chez vous, moi dans les logiciels que j'écrit, ça arrive aussi assez régulièrement qu'il y aie des bugs. Cela se traite avec un processus de relecture de code, de test et de validation, ainsi qu'avec un peu de réactivité pour corriger les problèmes qui sont passés au travers et qui surviennent en production. Fort heureusement, je ne travaille pas sur des réacteurs nucléaires ou autre systèmes pouvant mettre en danger la vie de personnes. Sinon, ce process de développement et de test serait bien différent pour réduire beaucoup plus la probabilité de problèmes en production ainsi que leurs conséquences. Vous avez une solution pour écrire du code sans bug du premier coup? Pour écrire un cahier des charge qui prend en compte absolument toutes les inconnues dès le début? Je pense que ça intéresse pas mal de monde si c'est le cas.
Pour que ce soit bien clair: l'arrêt dutréacteur au bout de 30 mois était prévu quoi qu'il arrive, indépendament du défaut du couvercle. Il s'agit de vérifier que tout se passe bien après quelques temps de fonctionnement et qu'il n'y a pas eu de hroblème non détecté lors de la construction, que les composants ne vieillissent ou s'usent pas de façon prématurée, etc.
Vu que le réacteur est arrêté pour cette procédure de contrôle tout à fait normale, autant en profiter pour changer le couvercle non conforme à la spécification par la même occasion.
Conclusion: tout se passe comme prévu avec l'extrême prudence habituelle de l'industrie nucléaire, grâce à laquelle il s'agit d'un des secteurs de l'industrie les plus sûrs, en tout cas si on compare dans le domaine de la production d'énergie (chiffres un peu anciens vers 2000, mais ça n'a pas énormément changé depuis malgré une catastrophe et une poignée d'incidents dont on a beaucoup entendu parler).
En demandant poliment au LLM, il obtient un accès ssh à la machine, y déploie un serveur de torrent ainsi qu'un mineur de cryptomonnaies.
Contacté à ce sujet, des gens de Meta auraient répondu "oui oui, c'est normal, c'est le comportement attendu de ce service".
Donc si vous êtes aux USA et que vous avez besoin d'un serveur gratuit pour des activités douteuses, profitez-en, Meta vous offre l'hébergement et ne demande aucune preuve d'identité à part une adresse mail!
Il me semble qu'il existe des mécanismes plus largement reconnus pour garantir l'imprévisibilité, comme ceux utilisés par exemple dans les loteries nationales.
Pour le besoin évoqué, c'est peut-être davantage une question de principe : faire un choix didactique.
La propriété qui est considérée comme importante est que les nombres aléatoires retenus soient vérifiables par le public.
The random sources should not include anything that any reasonable person would believe to be under the control or influence of the IETF or its components, such as IETF meeting attendance statistics, numbers of documents issued, or the like.
L'idée est donc d'annoncer à l'avance comment le tirage au sort sera fait, quelle source pseudo-aléatoire publique sera utilisée, et comment elle sera traitée pour obtenir les résultats. Ainsi, tout le monde peut indépendament se procurer le résultat de la source aléatoire, exécuter l'algorithme, et s'assurer qu'il obtient bien le résultat annoncé.
La section 3.3 explique comment mesurer l'entropie des sources et faire en sorte que le résultat soit suffisament aléatoire.
La RFC mentionne d'autres sources possibles, incluant les numéros gagnants du loto:
Particularly for government run lotteries, great care is usually taken to see that they produce random quantities. Even in the unlikely case one were to have been rigged, it would almost certainly be in connection with winning money in the lottery, not in connection with IETF use.
Le fait que la source utilisée est imparfaite est bien pris en compte, mais, compte tenu des enjeux, elle est jugée acceptable. En gros: si vous pouvez manipuler le cours de la bourse (ou les numéros du loto) avec une telle précision, vous n'avez probablement aucun intérêt à utiliser vos capacités pour fausser les décisions de l'IETF, il y a des choses plus faciles et plus profitables à faire.
On peut noter que avant la mise en place de cet algorithme, la méthode de tirage au sort utilisée était de mettre des bouts de papier dans un réceptacle, puis de sélectionner une personne pour choisir les élus.
La RFC a été mise à jour par la suite (postérieur à son utilisation pour le choix du préfixe 'xn'), et elle donne d'autres raisons de ne pas utiliser les indices boursiers:
(Experience has indicated that stock prices and/or volumes are a poor source of unambiguous data due trading suspensions, company mergers, delistings, splits, multiple markets, etc.)
La section 5 ("Real world problems") revient un peu plus en détail sur le sujet. Elle se conclut en recommendant de choisir plutôt les numéros du loto, dont le tirage est moins susceptible d'être annulé, les résultats sont dans une forme bien définie et qui ne change que très rarement. On ne peut décidément pas faire confiance au monde de la finance pour quoi que ce soit, même pas pour produire des nombres aléatoires de façon fiable!
Puisqu'on parle d'utiliser le cours de la bourse pour générer des nombres aléatoires, c'est l'occasion de faire de la pub pour le geohashing, un loisir qui consiste à se rendre à un point dont les coordonnées GPS sont calculées selon une méthode similaire.
Je n'ai encore croisé personne dans mes expéditions (assez irrégulières je dois l'admettre).
Dans un espace vectoriel, l'orthogonalité implique l'indépendance linéaire. Donc dire que deux concepts sont orthogonaux, c'est juste une façon compliquée de dire qu'ils sont indépendants?
C'est surtout la monoculture de chrome/blink qui fait que les choses peuvent arriver rapidement. Finalement en temps que développeur de navigateur web, je préférais l'époque où la référence cwétait internet explorer, avec des versions ayant une durée de vie de plusieurs années et pas des nouveaux trucs chaque mois.
Ah ouais tu trouves? J'ai l'impression d'avoir plutôt lu des articles mal structurés, beaucoup trop longs, avec la même info répétée à plusieurs endroits. Alors certes, les phrases sont grammaticalement correctes, mais la forme d'un texte, ça va plus noin que ça.
C'est un peu la même chose que quand on regarde du vibe-code: chaque fonction prise isolément est propre comme un exemple de stack overflow, mais, dès que on prend de la hauteur, il n'y a aucune cohérence d'ensemble, des répétitions, etc.
J'imagine que dans un cas comme dans l'autre, c'est possible de travailler fonction par fonction ou paragraphe par paragraphe pour éviter ça. Mais dans ce cas, finalement, l'exercice de réflexion en amont est quand même fait par un.e humain.e et je doute que le résultat soit produit franchement plus vite qu'en finissant à la main.
On peut aussi l'utiliser pour découper du nylon (cordes, bandes, pièces de tissu) en le faisant fondre à température contrôlée et localisée, ce qui évite que ça s'effile.
J'ai voté (sans surprise?) "L'étain, le fer à souder et des composants élec. " mais je sais aussi faire "Des matériaux comestibles en cuisine". Il ne faut cependant surtout pas mélanger les deux.
C'est à dire que, parmi tous les trucs bénéfiques qui ont un impact écologique, pourquoi refuser spécifiquement le dernier arrivé ?
qui a dit qu'on ne pouvait refuser que le dernier? Je connaît plein de gens qui préfèrent le train à l'avion, le vélo à la voiture, le matériel informatique d'occasion au neuf, le logiciel libre au logiciel propriétaire, le tout même si ça peut rendre la vie plus difficile.
La différence quand c'est le "dernier arrivé", c'est que la remise en question est plus facile. Si on avait préféré le train au tout voiture au siècle dernier, on aurait un reseau de train dense et bien entretenu et pas d'autoroutes. Si on avait préfére le logiciel libre partout, Microsoft n'existerait plus. Il en sera de même avec l'IA, qui va largement transfor@er au moins le web, et sûrement plein d'autres aspects de nos vies et de la façon dont on accède à de l'information a minima. Ce qui rendra de plus en plus difficile de faire marche arrière si on voulait un jour.
La Open AI a fait n'importe quoi, comme à son habitude.
Ah oui c'est certain, mais c'était pas ça la question. Malgré le fait que les équipes techniques ont fait n'importe quoi, ont été infoutues d'isoler correctement leur test de l'accès à internet, et ont contaminé rubygems (entre autres problèmes, j'imagine), l'histoire qui est communiquée est "notre IA est très forte et s'est échappée", pas "nos ingés sont incompétents/mal formés/n'ont pas les moyens de faire leur travail correctement et sont infoutus d'installer un réseau isolé de l'internet pour faire leurs tests".
C'est comme si une centrale nucléaire avait explosé et que la communication était "oui, nous avons décidé oe livrer l'énergie à nos clients directement sous forme de particules radioactives plutôt que de la transformer d'abord en électricité, nous espérons que vous appréciez ce nouveau fonctionnement en circuit court avec une meilleure rentabilité énergétique". Il y a pas rien en-dessous, mais ça rajoute une couche d'irresponsabilité supplémentaire (ou l'insule par-dessus la blessure comme on dit en anglais).
Alors, soit on croit au risque de l'émergence d'une AGI prochainement, et dans ce cas la faute de OpenAI est dangereuse, comme si un labo oe biologie avait laissé s'échaper un virus dangereux. Soit on y croit pas et c'est quand même un incident de sécurité avec une attaque d'une "supply chain" puis d'un concurrent par des méthodes illégales et ça mérite des grosses amendes. Mais non, ils sont plutôt en train oe se vanter de ce qu'il s'est passé et y'aura probabement aucune conséquence ou une amende symbolique har rapport aux bénéfices de la campagne de communication.
OpenAI: ohlàlà regardez nos agents ils sont vraiment trop forts ils ont contourné toutes nos protections et attaqué un de nos concurrents, cette technologie est vraiment puissante et dangereuse
HuggingFace: pas de problèmes les gars, nos agents à nous sont encore plus forts, nous avons pu contrer l'attaque, tout est sous contrôle!
Anthropic: (se réveille de la sieste) … hé! Moi aussi j'ai un agent vraiment trop fort qui s'est échappé!
Oui, c'est du marketing avec un bon vieux concours de qui a la plus grosse, pour impressionner les acheteurs et faire croire que les agents ont des capacités incroyables pour contourner les barrières et dépasser les capacités des humains qui les ont lancé, et que la seule protection qui fonctionne, c'est de jeter encore plus d'agents dans la bataille.
mettre Stallman à côté d'authentique nazi, je trouve ça douteux
effectivement pour Stallman il s'agit plutôt de pédophilie que de nazisme. Je ne sais pas lequel des deux devrait être le plus gêné de se trouver à côté de l'autre, cependant.
# Méthode de travail
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 8 (+6/-1).
Tu décris une méthode qui ressemble beaucoup au cycle en V traditionnel.
Il y a beaucoup de gens qui ne travaillent pas comme ça, mais avec des méthodes dites "agiles" ou ces étapes ne sont pas du tout découpées de la même façon.
En ce qui me concerne, l'écriture de code n'est pas seulement pour dire à la machine ce qu'elle doit faire. Il s'agit d'une méthode de formalisation des besoins exprimés. Cette formalisation dans un langage strict et structuré fait que on se rend compte, lors de l'écriture du code, qu'il y a des cas non prévus dans la spécification, voire des informations contradictoires. Cela permet aussi de se poser la question des bonnes structures de données à adopter pour faire le traitement de façon efficace.
Il y a donc constamment des allers-retours entre l'écriture du code et la rédaction de la spécification.
Je ne suis pas capable de faire ce travail en exprimant les choses en langage naturel (français ou anglais). Je ne pense pas que la personne qui rédige la spécification pourrait remplacer mon travail par l'utilisation d'un LLM. Je ne pense même pas qu'elle pourrait réduire mon travail: si une partie du code était générée par un LLM, ça me ferait d'autant plus de code à relire et à comprendre. Pour moi cela demande plus d'effort de lire et comprendre le code de quelqu'un d'autre, que d'écrire moi-même du code. De plus, le processus mis en place (écriture par une personne et relecture par une autre) est un moyen supplémentaire de détecter les divergences avec la spécification et les oublis. Lors de l'utilisation d'un LLM, c'est la première chose qui va sauter: le développeur ayant demandé au LLM de générer le code, ne l'a pas écrit, mais il l'a relu. Il va donc penser qu'une deuxième relecture n'est pas utile.
Il y a des cas où le code n'est pas critique, suffisamment simple, et où ça peut marcher. Mais dans ce cas, je ne vois pas l'intérêt d'en faire un journal sur linuxfr, car on apprendra rien de nouveau.
# Non.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'IA et. Évalué à 9 (+6/-0).
22 ans de moulage sur Linuxfr et ce serait un contributeur débutant? Je n'y crois pas…
C'est pas compliqué: les personnes qui n'ont ni fait l'effort d'écrire leur propre code, ni fait l'effort d'écrire peur propre journal, personne n'a envie de lire le résultat (ni le code, ni le journal). Si iels veulent des commentaires positifs et encourageants, après tout, ils peuvent en demander à leur LLM préféré qui saura faire ça très bien. Pourquoi embêter des humains pour ça? Il faut pousser la démarche jusqu'au bout, remplacer les développeurs, mais aussi les utilisateurs et les détracteurs du projet par des LLM. Ainsi les gens pourront enfin cesser de passer du temps devant leur ordinateur, pourront sortir prendre le soleil, et le monde sera meilleur.
[^] # Re: hum
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 5 (+3/-1).
Comme je l'ai écrit, la réponse aux questions dépend beaucoup du projet et aussi des raisons pour lesquelles on souhaite (ou pas) rejeter l'utilisation de LLMs.
Si les raisons sont une inquiétude sur la qualité du code ou des rapports de sécurité (avec un rapport qualité/volume produit), alors, effectivement, on peut limiter le problème d'autres façons (en disant simplement qu'on rejette les contributions de mauvaise qualité, peu importe comment elles sont faites).
Ça soulève d'autres questions. Je reprend les cas que je connaît. Dans Haiku, on reçoit souvent des contributions (faites à la main) qui ne vont pas au bout des choses. On aide les gens à mieux comprendre l'architecture, à améliorer leur proposition s'ils en ont envie, ou bien on reprend le truc en main et on finalise ou on réécrit les changements. Ce faisant, on a en tant que relecteur la satisfaction d'aider quelqu'un à monter en compétence, et les gens qui envoient des patchs en profitent pour apprendre des choses (clairement sans Haiku je n'aurais jamais acquis autant de connaissances sur le fonctionnement des systèmes UNIX, la programmation en C++, la conception d'IHM, …).
Dans ce contexte on a même réussi à encadrer des contributeurs âgés de 13 à 17 ans dans le cadre du Google Code-In. Niveau qualité du code produit, il est clair qu'un LLM aujourd'hui est loin devant ce qu'on peut attendre d'un adolescent de 13 ans. Cependant, nous avons pu faire fonctionner ce mode de contribution assez spécial, en particulier parce que nous avons produit une liste de tâches très détaillée et aussi parce que nous avons recruté les participants d'une année pour aider à encadrer ceux de l'année suivante.
Je ne pense pas que on puisse avoir une telle qualité d'échanges humains si on reçoit des masses de contributions générées par LLM. Dans le cas de Haiku encore, c'est déjà difficile sans LLM de répondre à toutes les demandes de revue de code. Et il n'est pas question ici de mettre en place un système de "réponse automatique" par LLM (on l'a fait par contre sur les aspects qui sont automatisables, comme le formatage du code, et il faudrait développer ou mettre en place d'autres outils par exemple pour le respect des conventions de nommage).
Voilà pour le cas où l'argument est sur la qualité et le volume des contributions. Ça dépend du volume de contributions reçu, de l'intérêt que les développeurs ont pour le partage de compétence via la revue de code, de la disponibilité des contributeurs. Pour des exemples de projets qui font des choix très différents parce qu'ils ont des contraintes différentes, citons sqlite (c'est impossible de leur faire accepter un patch, ils préfèrent réécrire le code eux-mêmes), ou Linux (très gros volume de contribution, ne peut pas trop se permettre d'avoir des failles de sécurité, pas assez de gens pour traiter toutes les contributions reçues: l'utilisation de LLM peut être une bonne solution une fois qu'on en est là).
Ensuite il y a l'argument du copyright. Là je peux citer Ryan Gordon qui travaille sur SDL. Lorsqu'il reçoit un patch généré par LLM, son souci principal est que cela pourrait être recopié de code source existant par ailleurs dans les données d'entraînement du LLM utilisé et sans en citer l'auteur. Devant l'incertitude au niveau de la license, l'option qu'il retient est de réécrire le code de façon différente (ce aui est d'autant plus difficile que le patch est simple). On a fait ce genre de choses chez Haiku aussi: une personne a vibe codé un tas de modifications (autour de la gestion de l'USB et des périphériques MIDI en particulier), un développeur de Haiku a regardé les changements et réécrit des correctifs de sa propre main. Là aussi, les enjeux ne sont pas les mêmes selon le projet. J'ai travaillé dans des entreprises où le risque de contamination du code interne par de la GPL faisait vraiment très peur aux juristes (de façon justifiée ou pas). Il y a d'autres projets où c'est beaucoup plus détendu là dessus (par exemple Linux qui n'est pas connu pour insister très fortement sur le respect de la GPL).
Enfin il y a l'argument des conséquences écologiques et en utilisation de ressources. Et là aussi le compromis change selon, disons les orientations politiques et éthiques du projet. Peut-être qu'on en a rien à faire. Peut-être que la fin justifie les moyens. Ou peut-être que c'est un projet très orienté sur la réduction des ressources et l'informatique frugale, auquel cas, le choix d'utiliser massivement des LLM serait discutable. Il n'y a pas une seule réponse et ça n'a pas forcément à être 100% oui ou non. De la même façon que plein de gens sont écologistes mais prennent quand même l'avion pour partir en vacances parce que "ça change rien, l'avion décollera peu importe si je suis dedans ou pas". Bon courage pour calculer le bilan carbone précis de chaque contribution, et savoir si oui ou non, le résultat net est positif. Je ne pense pas que ça soit faisable, et donc, la solution est forcément une décision arbitraire, qui peut être très simple (pas d'IA, ou full open bar) ou plus nuancée, ou décidée au cas par cas selon l'humeur du moment.
Pour en revenir au cas pratique de Haiku: la raison officielle qui conduit à interdire l'utilisation de LLMs, ce sont les problèmes de copyright. Dans ce contexte, il n'y a pas de problème si quelqu'un fournit un cas de test généré par un LLM (il servira à tester la correction mais ne sera pas intégré dans le code source), ou si quelqu'un fournit une contribution contenant du code généré par LLM (elle ne sera pas intégrée mais elle pourra servir de référence pour refaire une implémentation indépendante). Bien sûr cette approche n'a aucun sens si l'argument retenu était celui de la consommation de ressources (on fait 2 fois le travail: de ce point de vue c'est donc moins bien); et il n'a aucun sens non plus du point de vue de la qualité des contributions et de la montée en compétence des contributeurs (on passe du temps à réécrire du code qui existe déjà, on ne crédite pas directement les gens ayant utilisé le LLM comme auteurs des changements mais seulement comme ayant identifié le problème).
Il y a encore d'autres raisons pour exclure les LLMs que j'ai entendues, mais sur lesquelles j'ai moins réfléchi. Par exemple, le fait que les LLMs sont peut-être vraiment conscients, et que c'est donc une forme d'esclavage ou d'exploitation animale de les utiliser; ou encore des raisons religieuses, dans certaines religions, tenter de recréer l'intelligence humaine qui est l'aboutissement du travail de Dieu, c'est mal vu (je résume n'importe comment parce que je suis totalement incompétent dans ce domaine). Je suppose que cela amènerait encore des réponses différentes.
[^] # Re: hum
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 6 (+3/-0).
J'ai un avis sur la question, mais je vais le formuler sous forme de auestions pour que chacun puisse prendre sa propre décision pour ses propres projets (et la réponse n'est pas forcément la même dans tous les cas, par exemple en ce qui me concerne, l'approche de la sécurité dans Haiku n'est pas la même que dans mon emploi salarié, ou que dans d'autres projets que je maintiens):
Ce sont des questions qui se posaient déjà avant l'arrivée de l'IA. Dans Haiku par exemple on s'attend à ce que les contributeurs fasse un peu d'efforts pour formater leur code correctement selon nos règles (certaines personnes refusent de le faire et considèrent que c'est une perte de temps), le tester avant de nous l'envoyer (on reçoit régulièrement des propositions de changements qui ne compilent même pas), répondre aux questions des développeurs sans s'énerver, parfois devoir faire du refactoring pour rendre une solution plus générale plutôt que un patch contournant le problème, etc. C'est assez exigeant, mais le but est que les gens qui commencent à participer à Haiku par de petites contributions s'impliquent de plus en plus et que leur travail nécessite de moins en moins de revue pour être intégré.
Lorsque la contribution externe est générée par LLM, le rapport de force change beaucoup. Il y a alors deux options faciles: interdire les LLM pour tout le monde, ou utiliser soi-même des LLM pour tenter de rééquilibrer. Il y a plein d'options moins faciles: accepter le déséquilibre, interdire toutes les contributions externes, …
[^] # Re: LOL
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Element Pro c'est de la "merde absolue", d'après un type de la Commission européenne. Évalué à 5 (+2/-0).
Du côté des serveurs je ne sais pas, mais du côté des clients, l'implémentation IMAP de Google fait des choix assez inhabituels, et la mauvaise intégration avec les clients "lourds" existants a conduit pas mal de monde à oublier l'existence de Thunderbird et de ses concurrents pour utiliser exclusivement le webmail.
Il se passe aussi un peu la même chose avec le web: Google n'a pas réussi à imposer ses spécifications au W3C (qui a un fonctionnement à peu près aussi lourd que celui de la XSF) et donc cela a abouti à la création d'un organisme de standardisation concurrent, le WhatWG, avec la spécification de HTML5 et de plein d'autres trucs dont certains abandonnés entretemps (QUIC, SDCH, SPDY, HTTP 2, HTTP 3, …).
On peut donc imaginer ce qu'il se serait passé si la XSF avait accepté telle quelle la spécification de Google:
Bref, Google a fait un truc fonctionnant avec une seule implémentation de client et une seule implémentation de serveur. C'est beaucoup plus facile de faire ça que de faire une spécification interopérable pour un protocole standardisé. Ils n'avaient aucun intérêt à faire l'autre moitié du travail, ni à attendre que ça soit fait avant de déployer leur client. Je ne vois pas bien ce que la XSF aurait pu faire pour changer ça.
[^] # Re: en fr
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien AT&T : Quand l'iPhone 18 Pro se transforme définitivement en iPod. Évalué à 7 (+4/-0).
Et ben j'aurais bien aimé avoir plus de détail sur ce bug qui n'est pas réparable et nécessite carrément de changer le téléphone. Suppositions possibles (mais il y en a sûrement plein d'autres):
[^] # Re: ça craint !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien L’extrême droite prépare un coup d’État institutionnel. Évalué à 5 (+2/-0).
Et malgré tout ça, il y a un candidat wallon qui veut rejoindre la France (avec le défi d'obtenir 500 signatures ET la nationalité française avant de pouvoir se présenter)
[^] # Re: Alors pour qui voter？
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien L’extrême droite prépare un coup d’État institutionnel. Évalué à 7 (+4/-0).
De plus, il me semble que dans l'élection où il y avait un duel Biden-Trump, c'est Biden qui a gagné. Question boulevard, on a fait mieux, non?
[^] # Re: Kobo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Rakuten France : le site de vente en ligne cessera son activité à partir du 1ᵉʳ octobre. Évalué à 10 (+7/-0).
Il me semble que seule la "marketplace" (ce qu'il restait de PriceMinister suite à son rachat par Rakuten) est concernée par cette fermeture. Victime de la concurrence d'Amazon, leboncoin, wish, temu, aliexpress, … mais peut-être aussi du renommage en "Rakuten marketplace" alors que le nom de PriceMinister était assez connu à l'époque.
[^] # Re: extrait
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien L'EPR de Flamanville va être arrêté pendant un an, moins de deux ans après sa mise en service. Évalué à 5 (+3/-1).
Je ne vois pas le rapport entre le défaut de couvercle de l'EPR de Flamanville (qui n'a pas subi d'incident, seulement un remplacement préventif au bout de 2 ans pour une pièce risquant de vieillir prématurément à cause d'un défaut de fabrication constaté bien avant qu'il y aie un problème - pas d'un défaut de conception) et la centrale de Fukushima. Du coup je ne suis pas bien le raisonnement.
Quant aux cygnes noirs, y
leur population est estimée entre 300000 et 500000 individus. Ils sont donc moins rares que d'autres espèces d'oiseaux menacées, et beaucoup plus facile à trouver que les accidents nucléaires.
[^] # Re: extrait
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien L'EPR de Flamanville va être arrêté pendant un an, moins de deux ans après sa mise en service. Évalué à 10 (+10/-1).
Dans le cas de l'EPR: il y a eu une erreur qui a conduit à une pièce non conforme au cahier des charges (pourcentage de carbone plus élevé que ce qui était demandé).
Donc je comprend pas le commentaire. Le cahier des charges demandait un truc, la pièce produite ne répondait pas à ce qui était demandé. Ensuite se pose la question "est-ce que c'est grave" et dans ce cas la réponse est: pour le fond de cuve, non, parce qu'on peut surveiller sa dégradation et intervenir lorsque ce sera nécessaire. Pour le couvercle, oui un peu, parce que on ne peut pas l'inspecter aussi facilement. Cependant, la conséquence est seulement un vieillissement accéléré, ça ne mettait pas en danger le fonctionnement de la centrale pendant les 30 mois d'essai.
Donc, mise en place d'un plan pour remplacer la pièce défectueuse au moment opportun sans retarder encore la mise en service et sans prendre de risque inutile.
La méthode me semble plutôt la bonne, précisément celle qui fait que on aboutit pas à une désintégration de navette, un déraillement de TGV, ou une implosion de sous-marin.
La transparence sur les problèmes fait par contre que tout le monde est au courant du moindre souci, ce qui donne l'impression qu'il y a tout le temps des problèmes.
Je sais pas comment ça se passe chez vous, moi dans les logiciels que j'écrit, ça arrive aussi assez régulièrement qu'il y aie des bugs. Cela se traite avec un processus de relecture de code, de test et de validation, ainsi qu'avec un peu de réactivité pour corriger les problèmes qui sont passés au travers et qui surviennent en production. Fort heureusement, je ne travaille pas sur des réacteurs nucléaires ou autre systèmes pouvant mettre en danger la vie de personnes. Sinon, ce process de développement et de test serait bien différent pour réduire beaucoup plus la probabilité de problèmes en production ainsi que leurs conséquences. Vous avez une solution pour écrire du code sans bug du premier coup? Pour écrire un cahier des charge qui prend en compte absolument toutes les inconnues dès le début? Je pense que ça intéresse pas mal de monde si c'est le cas.
[^] # Re: extrait
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien L'EPR de Flamanville va être arrêté pendant un an, moins de deux ans après sa mise en service. Évalué à 10 (+9/-1).
Pour que ce soit bien clair: l'arrêt dutréacteur au bout de 30 mois était prévu quoi qu'il arrive, indépendament du défaut du couvercle. Il s'agit de vérifier que tout se passe bien après quelques temps de fonctionnement et qu'il n'y a pas eu de hroblème non détecté lors de la construction, que les composants ne vieillissent ou s'usent pas de façon prématurée, etc.
Vu que le réacteur est arrêté pour cette procédure de contrôle tout à fait normale, autant en profiter pour changer le couvercle non conforme à la spécification par la même occasion.
Conclusion: tout se passe comme prévu avec l'extrême prudence habituelle de l'industrie nucléaire, grâce à laquelle il s'agit d'un des secteurs de l'industrie les plus sûrs, en tout cas si on compare dans le domaine de la production d'énergie (chiffres un peu anciens vers 2000, mais ça n'a pas énormément changé depuis malgré une catastrophe et une poignée d'incidents dont on a beaucoup entendu parler).
[^] # Re: Et un long thread d’analyse de ce qu’on trouve dans ce système de fichier
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien I asked Meta’s Muse for its filesystem and it sent me 6.8 GB. Évalué à 10 (+7/-0).
En demandant poliment au LLM, il obtient un accès ssh à la machine, y déploie un serveur de torrent ainsi qu'un mineur de cryptomonnaies.
Contacté à ce sujet, des gens de Meta auraient répondu "oui oui, c'est normal, c'est le comportement attendu de ce service".
Donc si vous êtes aux USA et que vous avez besoin d'un serveur gratuit pour des activités douteuses, profitez-en, Meta vous offre l'hébergement et ne demande aucune preuve d'identité à part une adresse mail!
[^] # Re: C’est pas bête
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La folle histoire des noms de domaine internationalisés. Évalué à 10 (+11/-0).
Il y a bien sûr une RFC qui explique bien tout.
La propriété qui est considérée comme importante est que les nombres aléatoires retenus soient vérifiables par le public.
L'idée est donc d'annoncer à l'avance comment le tirage au sort sera fait, quelle source pseudo-aléatoire publique sera utilisée, et comment elle sera traitée pour obtenir les résultats. Ainsi, tout le monde peut indépendament se procurer le résultat de la source aléatoire, exécuter l'algorithme, et s'assurer qu'il obtient bien le résultat annoncé.
La section 3.3 explique comment mesurer l'entropie des sources et faire en sorte que le résultat soit suffisament aléatoire.
La RFC mentionne d'autres sources possibles, incluant les numéros gagnants du loto:
Le fait que la source utilisée est imparfaite est bien pris en compte, mais, compte tenu des enjeux, elle est jugée acceptable. En gros: si vous pouvez manipuler le cours de la bourse (ou les numéros du loto) avec une telle précision, vous n'avez probablement aucun intérêt à utiliser vos capacités pour fausser les décisions de l'IETF, il y a des choses plus faciles et plus profitables à faire.
On peut noter que avant la mise en place de cet algorithme, la méthode de tirage au sort utilisée était de mettre des bouts de papier dans un réceptacle, puis de sélectionner une personne pour choisir les élus.
La RFC a été mise à jour par la suite (postérieur à son utilisation pour le choix du préfixe 'xn'), et elle donne d'autres raisons de ne pas utiliser les indices boursiers:
La section 5 ("Real world problems") revient un peu plus en détail sur le sujet. Elle se conclut en recommendant de choisir plutôt les numéros du loto, dont le tirage est moins susceptible d'être annulé, les résultats sont dans une forme bien définie et qui ne change que très rarement. On ne peut décidément pas faire confiance au monde de la finance pour quoi que ce soit, même pas pour produire des nombres aléatoires de façon fiable!
[^] # Re: C’est pas bête
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La folle histoire des noms de domaine internationalisés. Évalué à 4 (+1/-0).
Puisqu'on parle d'utiliser le cours de la bourse pour générer des nombres aléatoires, c'est l'occasion de faire de la pub pour le geohashing, un loisir qui consiste à se rendre à un point dont les coordonnées GPS sont calculées selon une méthode similaire.
Je n'ai encore croisé personne dans mes expéditions (assez irrégulières je dois l'admettre).
[^] # Re: Dans quel monde cette personne vit-elle ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Are LLMs still surprisingly bad at some simple tasks?. Évalué à 7 (+4/-0).
Dans un espace vectoriel, l'orthogonalité implique l'indépendance linéaire. Donc dire que deux concepts sont orthogonaux, c'est juste une façon compliquée de dire qu'ils sont indépendants?
[^] # Re: très intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Réquisitoire contre JPEG XL (dans les navigateurs web). Évalué à 4 (+1/-0). Dernière modification le 18 septembre 2026 à 23:19.
C'est surtout la monoculture de chrome/blink qui fait que les choses peuvent arriver rapidement. Finalement en temps que développeur de navigateur web, je préférais l'époque où la référence cwétait internet explorer, avec des versions ayant une durée de vie de plusieurs années et pas des nouveaux trucs chaque mois.
[^] # Re: Ne mélangeons pas
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 25 ans de journaux Linuxfr dans mon flux RSS. Évalué à 10 (+9/-0).
Ah ouais tu trouves? J'ai l'impression d'avoir plutôt lu des articles mal structurés, beaucoup trop longs, avec la même info répétée à plusieurs endroits. Alors certes, les phrases sont grammaticalement correctes, mais la forme d'un texte, ça va plus noin que ça.
C'est un peu la même chose que quand on regarde du vibe-code: chaque fonction prise isolément est propre comme un exemple de stack overflow, mais, dès que on prend de la hauteur, il n'y a aucune cohérence d'ensemble, des répétitions, etc.
J'imagine que dans un cas comme dans l'autre, c'est possible de travailler fonction par fonction ou paragraphe par paragraphe pour éviter ça. Mais dans ce cas, finalement, l'exercice de réflexion en amont est quand même fait par un.e humain.e et je doute que le résultat soit produit franchement plus vite qu'en finissant à la main.
[^] # Re: [Des matériaux souples]
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos compétences digitales ?. Évalué à 3 (+0/-0).
Pour les matériaux comestibles aussi, c'est mieux si ils sont souples. Sinon, attention les dents…
[^] # Re: Une seule réponse?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos compétences digitales ?. Évalué à 4 (+1/-0).
On peut aussi l'utiliser pour découper du nylon (cordes, bandes, pièces de tissu) en le faisant fondre à température contrôlée et localisée, ce qui évite que ça s'effile.
# Une seule réponse?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos compétences digitales ?. Évalué à 7 (+4/-0).
J'ai voté (sans surprise?) "L'étain, le fer à souder et des composants élec. " mais je sais aussi faire "Des matériaux comestibles en cuisine". Il ne faut cependant surtout pas mélanger les deux.
[^] # Re: David Madore
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien ia openai affirme avoir resolu le probleme de navier-stoke ... ou pas. Évalué à 10 (+7/-0). Dernière modification le 15 septembre 2026 à 00:15.
qui a dit qu'on ne pouvait refuser que le dernier? Je connaît plein de gens qui préfèrent le train à l'avion, le vélo à la voiture, le matériel informatique d'occasion au neuf, le logiciel libre au logiciel propriétaire, le tout même si ça peut rendre la vie plus difficile.
La différence quand c'est le "dernier arrivé", c'est que la remise en question est plus facile. Si on avait préféré le train au tout voiture au siècle dernier, on aurait un reseau de train dense et bien entretenu et pas d'autoroutes. Si on avait préfére le logiciel libre partout, Microsoft n'existerait plus. Il en sera de même avec l'IA, qui va largement transfor@er au moins le web, et sûrement plein d'autres aspects de nos vies et de la façon dont on accède à de l'information a minima. Ce qui rendra de plus en plus difficile de faire marche arrière si on voulait un jour.
[^] # Re: Description de l'article
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Une description pas trop technique de l'attaque des 700 agents d'Open IA sur hugging Face de juillet dernier (Article payant). Évalué à 8 (+5/-0).
Ah oui c'est certain, mais c'était pas ça la question. Malgré le fait que les équipes techniques ont fait n'importe quoi, ont été infoutues d'isoler correctement leur test de l'accès à internet, et ont contaminé rubygems (entre autres problèmes, j'imagine), l'histoire qui est communiquée est "notre IA est très forte et s'est échappée", pas "nos ingés sont incompétents/mal formés/n'ont pas les moyens de faire leur travail correctement et sont infoutus d'installer un réseau isolé de l'internet pour faire leurs tests".
C'est comme si une centrale nucléaire avait explosé et que la communication était "oui, nous avons décidé oe livrer l'énergie à nos clients directement sous forme de particules radioactives plutôt que de la transformer d'abord en électricité, nous espérons que vous appréciez ce nouveau fonctionnement en circuit court avec une meilleure rentabilité énergétique". Il y a pas rien en-dessous, mais ça rajoute une couche d'irresponsabilité supplémentaire (ou l'insule par-dessus la blessure comme on dit en anglais).
Alors, soit on croit au risque de l'émergence d'une AGI prochainement, et dans ce cas la faute de OpenAI est dangereuse, comme si un labo oe biologie avait laissé s'échaper un virus dangereux. Soit on y croit pas et c'est quand même un incident de sécurité avec une attaque d'une "supply chain" puis d'un concurrent par des méthodes illégales et ça mérite des grosses amendes. Mais non, ils sont plutôt en train oe se vanter de ce qu'il s'est passé et y'aura probabement aucune conséquence ou une amende symbolique har rapport aux bénéfices de la campagne de communication.
[^] # Re: Description de l'article
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Une description pas trop technique de l'attaque des 700 agents d'Open IA sur hugging Face de juillet dernier (Article payant). Évalué à 10 (+8/-1).
Oui, c'est du marketing avec un bon vieux concours de qui a la plus grosse, pour impressionner les acheteurs et faire croire que les agents ont des capacités incroyables pour contourner les barrières et dépasser les capacités des humains qui les ont lancé, et que la seule protection qui fonctionne, c'est de jeter encore plus d'agents dans la bataille.
[^] # Re: Liste à la Prévert
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien les petits gars bizarres à éviter du Logiciel Libre. Évalué à -3 (+3/-9).
effectivement pour Stallman il s'agit plutôt de pédophilie que de nazisme. Je ne sais pas lequel des deux devrait être le plus gêné de se trouver à côté de l'autre, cependant.