C'est réparti entre l'auteur du prompt et l'IA. Car si elle ne "raisonne" pas au sens humain du terme, elle a quand même des connaissances qu'elle met en œuvre.

Si tu dis "OK l'IA, je veux un système d'identification des utilisateurs en PHP", elle va chercher des modèles de code qu'elle a en mémoire. Donc même sans le préciser dans le prompt, tu peux être quasiment sûr qu'elle va y intégrer des bonnes pratiques associées (stockage des identifiants en BDD, sécurisation du mot de passe par hashage/salage, génération d'une page login, etc.) alors que tu ne l'a pas forcément précisé.

Ensuite, la main repasse sur l'auteur du prompt. Par exemple, "Tu peux me rajouter une fonction de réinitialisation du mot de passe qui envoie un email ?" si ça n'a pas été proposé par défaut.

Franchement, faut vraiment jeter un œil à ce que ça donne en pratique sur un chatGPT par exemple, c'est quand même assez dément. Et le côté conversationnel permet de rectifier le tir. Tu peux aussi lui coller ton code de départ et lui demander de se baser dessus.

Bon évidemment, plus c'est complexe et plus la version gratuite trouve ses limites et se perd dans la contextualisation. Sur un projet de très grande ampleur, je pense que même la version payante finit par se perdre...

Bof, c'est drôle à lire mais le code c'est une façon de structurer le raisonnement pour qu'il soit interprétable par un ordinateur, mais c'est pas le raisonnement lui-même.

En l’occurrence, même un développeur peut oublier des cas de figure, c'est même de plus en plus fréquent vu la complexité des outils qu'on développe aujourd'hui et la rapidité de production attendue. Et si dans certains cas l'erreur va être repérée en amont lors de la première exécution ou via des outils d'analyse de code/tests unitaires, il va y avoir des bugs qui vont ressortir 10 ans après parce que personne n'avait envisagé le cas de figure tordu qui mélange 28 conditions indépendantes pour arriver à un unique scénario qui fait tout planter.

Le plantage CrowdStrike, les MàJ de Windows, les caractères spéciaux d'iOS, les jeux vidéos... tout ça est pourtant produit par des développeurs qui écrivent du code.

Je pense donc qu'effectivement une IA est tout à fait capable de générer "from scratch" le code d'une fonctionnalité complète. Et pour avoir des gens qui s'en servent autour de moi, ça fait même plutôt du bon travail...

Quand j'ai testé GitHub Copilot, j'ai trouvé un gain de temps sur l'écriture de CSS pour un template Hugo. Il suggérait des blocs complets sur lesquels j'ai simplement eu besoin d'adapter quelques valeurs.

Après ça, j'ai testé le mode Chat (je considérais Copilot simple comme une auto completion de luxe), et il produisait une structure basique pour le HTML / CSS qu'il m'a suffit ensuite de peaufiner.

Ou pour du scripting Python, quand je traite par exemple des appels d'API, ça initialise les lignes de request et d'analyse des réponses. Derrière y'a plus qu'à tuner en mettant en oeuvre ce que je veux vraiment.

Voilà ce que j'appelle des structures récurrentes, le gain ici est de laisser la machine produire du code dont la valeur ajoutée ne vaut pas le temps que le dev aurait passé dessus. Permettant de se concentrer sur d'autres.

Et dans mon expérimentation de ce même l'outil, j'ai volontairement initié un projet Javascript (et je suis pas dev, et je connais encore moins le JS) pour évaluer la capacité d'assistance de l'outil. Il kickstart le projet sans problème, pisse du code qui répond à la spec en veux-tu en voilà, propose même une trame d'ajouts de feature, magnifique.

Mais dès qu'on arrive à une étape où la compétence du dev est indispensable, l'outil est inutile. Ce fut une expérimentation personnelle intéressante et enrichissante que j'ai pu mettre en comparaison avec celle réalisée dans un contexte pro avec un panel varié de développeurs (technos ou expérience).

Je ne sais pas ce que Google entend dans son quart de code généré par IA (probablement un énième bullshit), mais si je me base sur ma propre expérience, le plus pertinent est de demander à la machine les tâches simples et répétitives (bref, en gros de faire le taff d'un ordinateur) et laisser l'expertise et la réflexion à l'humain.

"Les expressions de concert et de conserve signifient toutes les deux « ensemble et en harmonie », mais de conserve ne s’emploie généralement qu’avec des verbes tels que naviguer, voyager, aller, etc., dans un contexte de voyage."

https://vitrinelinguistique.oqlf.gouv.qc.ca/22252/le-vocabulaire/nuances-semantiques/difference-entre-de-concert-et-de-conserve

(Raté )

Ça va beaucoup plus loin que ton user-agent. Il y a de multiples techniques et même avec un tor brower doté de toutes les extensions qui vont bien, ça reste possible.
Tu as notamment la liste des fontes installées sur ton OS, l'API WebGL du navigateur qui va utiliser ton GPU (ou SOC) pour tracer de la 3D de manière assez unique, ton matériel et les capteurs dispo (surtout sur mobile), la taille de ta fenêtre (ça semble bête mais il suffit parfois de 2 ou 3 critères pour définir ton unicité). J'en passe des plus ou moins complexes.

Etre unique n'est vraiment pas une bonne choses selon les utilisations, cela signifie, en effet comme vous venez d'avoir la preuve, qu'avec ou sans cookie on peut s'assurer que vous êtes bien le même utilisateur si vous garder le même moteur de recherche. Les utilisations peuvent être multiple, la bonne interrogation selon moi, est-ce déjà en place avec les grosses entités que l'on connait ?

Google et apple se sont désolidarisé de CMG sur cette histoire, ils n'assument pas, mais ça n'enlève rien au fait qu'une société tierce apparemment parvient à contourner les barrières en place, ou du moins c'est ce qu'elle a affirmé. Est-ce que vous avez du neuf là dessus depuis l'article de 404? Vous dîtes "c'est impossible" mais avez-vous creusé les dessous de cette histoire avec CMG?

Bug ou stratagème, la réponse officielle de YouTube c'est "nope, tout va bien, bouffez nos pubs, à plus, bisou!"

On parle certainement pas d'un problème affectant 4 mecs en Laponie Équatoriale, sinon ils n'auraient même pas pris la peine de réagir. Donc si le souci a dépassé le stade de l'anodin, juste répondre "non c'est okay", ben c'est pas du tout okay. Quoi qu'il y ait derrière.

Certains reviennent aussi du SemVer, car c'est pas très vendeur commercialement.

Le langage Java par exemple, utilisait au début du SemVer. Java 2, c'est en réalité Java 1.2. etc. Je crois que ça a changé vers Java 5 (où le 5 est véritablement devenu la vraie version de Java, et pas juste 1.5). Mais je ne suis pas spécialiste Java, donc je peux me tromper ^^

Idem avec Firefox. Pendant longtemps, c'était du SemVer. Mais Mozilla a décidé d'utiliser la même pratique que Chrome, car malgré les versions fréquentes, cela donnait un sentiment d'immobilisme (par exemple, la première version de Firefox 3.6 date de janvier 2010 quand la dernière, la 3.6.28 date de mars 2012 soit plus de 2 ans en 3.6.x). Maintenant, c'est un cycle rapide, avec un cycle de quelques semaines seulement.

Nope, c'est majeur.mineur.patch
Donc c'est la première version majeure :)

https://semver.org/lang/fr/

Un joli milestone pour ce beau projet !

Il est tout à fait normal dans la comm d'une version majeure de re-lister l'ensemble des améliorations qu'apporte cette version par rapport à la version majeure précédente. Ca ne se fait juste pas d'obliger les utilisateurs normaux à agréger eux-même les infos des releases notes des version intermédiaires et/ou beta. Même pour un outil comme celui-là.

Si l'exception pouvait être catché, très bien, il aurait fallu le faire. Je n'ai pas de problème avec l'idée et ne dit pas le contraire. Sauf que là, c'est une exception non prévue, puisque de fait, elle n'était pas attendue ni anticipée, sans doute à tord. Je dis juste que vous ne pouvez pas catcher toutes les exceptions sans réfléchir à chaque fois pourquoi vous le faites.

Je vais partir du cas général, pour arriver au contexte du bug cité plus haut.

Admettons que vous faites "a=1/2". Vous ne pouvez pas faire un catch d'une exception générique de cette opération, en disant j'attrape tout. Si vous avez une division par zéro, c'est incohérent car elle ne devrait pas arriver, donc autant tout faire tout planter (la mémoire peut être instable ou que sais-je). Si vous continuez l'exécution, vous arrivez de toute façon dans un état incohérent.

Autre exemple, si vous n'avez plus assez d'espace mémoire et avez une exception de ce type, vous pouvez essayer de catcher l'exception, mais si vous le faites, vous devez savoir comment vous en sortir sachant que vous n'avez pas assez de mémoire. Et peut être qu'il n'y a pas de bonne façon de s'en sortir ici. Donc en faisant un catch de cela sans y réfléchir, vous risquez de générer une boucle infinie d'exceptions indiquant qu'il n'y a pas assez de mémoire et comme vous catchez l'exception sans prendre des mesures adéquates, ça ne s'arrête jamais, ce qui sans doute n'a pas fait planter le noyau, mais je ne sais pas trop quel serait son état si un de ses drivers tourne à l'infini.

Mais c'est valable en général pour un algorithme. Si votre algorithme arrive dans état complètement illogique (enfin à priori), je dis qu'il faut tout faire planter, ne serait-ce que pour s'en rendre compte pendant les tests. C'est le principe des assertions.

Donc ici, pour revenir au contexte du "sensor"/driver qui ne s'en sortait pas à cause d'un accès mémoire invalide, vous pouvez faire un catch du tout et n'importe quoi, mais si vous faites ça, vous devez vous assurer que ce n'est pas une fausse bonne idée. Alors bien sûr, dans le contexte du noyau, sans doute aurait-il fallu simplement ignorer le chargement du drivers, émettre un rapport comme vous le dite, et passer à autre chose. Mais du coup, vous faites un catch en conscience de ce que vous faites, et vous acceptez de faire sauter un "sensor"/drivers lors du chargement de tous les drivers. Je n'ai pas du tout de problème avec l'idée. Mais au moment où prenez cette décision, vous acceptez que des drivers peuvent être manquants, et devez en tenir dans toute votre architecture, sinon, cela pourrait planter ailleurs, et ainsi de suite. Donc oui, avoir une tolérance à la panne, et faire simplement remonter un rapport aurait sans aucun doute été la bonne solution ici, mais ça ne s'improvise pas, il faut peut être en tenir compte ailleurs dans le reste de l'architecture.

Si vous faites des catchs partout sans prendre la mesure de ce vous êtes en train de faire, cela risque in fine de quand même planter mais beaucoup plus loin dans le programme, et là bon courage pour remonter le bug, surtout si vous avez pleins de rapports qui été pondus pendant 2 jours avant que ça ne plante quand même (je ne dis pas que c'est ce qui se serait passé ici, je n'en sais rien). D'autre part, comme c'est dans l'espace noyau, cela pourrait avoir des conséquences délétères non prévues si vous ne l'avez pas bien encadré. Vous évoquez les problèmes économiques, mais là, on parle d'une machine immobilisée par un BSOD. Étant donné qu'on est dans l'espace noyau, imaginez qu'en catchant tout et n'importe quoi, le noyau se mette à faire tout et n'importe quoi en dézinguant le système de fichier. Là, c'est carrément la cohérence des données du système de fichier que vous pouvez flinguer. Je ne sais pas si on peu en arriver là, et si les gardes fou du noyau sont suffisants, mais je veux dire que dans un contexte économique, il y a pire qu'un BSOD.

Mais encore une fois, dans le contexte de ce bug, il était sans doute possible d'accepter une tolérance à la panne, mais cette tolérance doit tout de même être anticipée et encadrée, ce qui n'a pas été le cas ici et c'est bien dommage. Mais ce n'est pas une décision qu'il faut prendre de manière légère et aveugle comme une règle générale (en tout cas pas pour moi).

Donc je ne dis pas "Donc si je comprend bien, comme il n'est pas possible de prévenir de tous les bugs, évitons d'essayer de prévenir de quelque bug que ce soit...", je dis "essayez de prévenir tous les bugs, y compris ceux que vous comprenez pas à l'avance, acceptez la tolérance à la panne, mais si un bug ou une panne non anticipée arrive quand même alors que vous ne l'avez pas prévu ni encadré, je ne crois pas qu'il faille faire un catch aveugle sans en mesurer les conséquences, d'autant qu'à force de faire ça, vous prenez le risque de rendre un bug silencieux lors des tests, et rendre vos remontées de bug plus pénibles et fastidieuses.

Si le bug est prévisible, ce n'est pas vraiment un bug, vu que vous qu'en l'anticipant, une correction s'impose d'elle même. A partir du moment où vous n'avez pas prévu le bug, il se produira, ce qui s'est produit ici. Maintenant, oui, si le correctif consiste à dire qu'on peut passer au fichier sys suivant, c'est pas grave, OK. Mais les bugs se produiront toujours parceque vous n'avez pas anticiper un problème, jamais autrement, à moins de travailler dans l'objectif de saboter le projet (ce qui peut être une piste cela dit). On peut toujours dire après coup, on aurait pu faire ceci ou cela, mais bon, résoudre le problème à postériori ne résou pas le problème à priori. Impossible de remonter dans le temps.

Donc soit vous décidez à priori que certains problèmes peuvent se poser et que vous pouvez ignorer le chargement fichier sys à priori en toute conscience, soit vous décidez à priori qu'aucun problème ne devrait se poser, car au moment où vous écrirez le code, vous considérerez que le problème que vous envisagez est impossible (à tord ou à raison), et que s'il se produit quand même, c'est que au moment où vous y pensez, vous ne savez pas pourquoi cela se produit. Soit vous tolérez l'erreur sans trop savoir ce que ça va donner (et éventuellement ce que cela va empirer), soit vous faite tout planter, en disant qu'il vaut mieux préserver l'intégrité du système, et notamment l'intégrité des données qu'il ne faut pas corrompre. Si le noyau arrive par exemple à un état non anticipé, est-ce qu'il vaut mieux générer un écran bleu ou continuer au risque de bousier le système de fichier ? Par exemple, et petite digression, j'ai entendu du dire que le noyau Linux était tellement stable qui ne générais pas de kernel panic même avec une mémoire instable. Personnellement, cela m'est déjà arrivé d'avoir une mémoire instable, le noyau n'a pas planté, et pourtant mon ordinateur faisait n'importe quoi (j'ai mis du temps à comprendre que c'était la mémoire le problème, enfin 2h). J'estime avoir eu de la chance que ça n'ait pas eu plus de conséquences sur mon système de fichiers. J'aurais préféré un kernel panic. Maintenant, dans le cas de cet article, je ne sais pas trier ce que peut être toléré comme erreur de ce qui ne peut pas l'être.

Ce que je dis en revanche, c'est que les bugs arrivent quelque soit les précautions prises. Donc par définition, si on n'anticipe pas un bug et son sens, c'est qu'on ne sais pas s'il faut faire tout planter, ou si on peut tolérer l'erreur. Pour tester un programme, on doit faire des tests, et mon propos initial supposait que des tests sur Crowdstrike avait bien été effectués avant la mise en production. Je me suis alors demandé comment des tests peuvent passer sur une machine de test et pas sur une machine en production ? Du fait qu'un programme C ne fait pas toujours planter un programme à cause d'un mauvais accès mémoire, seul le noyau fait planter le programme s'il se rend compte que l'accès porte sur un espace mémoire non autorisé. Mais si l'accès mémoire est autorisé au moment du test, bien qu'incohérent, le noyau n'arrête rien, et le programme C n'arrête rien non plus, ce qui n'aurait pas été le cas d'autres langages (Pour les langages système, on peut citer Rust). Cela peut être une hypothèse (entre autres) de pourquoi le bug a passé les tests : l'environnement mémoire n'était pas le même, et dans un cas, le noyau ne fait pas planter le programme, dans l'autre il faitt planter le programme (et lui même), et pas de chance, ça tombe en prod. Ben ça, ça arrive typiquement avec C/C++.

Donc au final, un langage moins laxiste sur la gestion de la mémoire, si les hypothèses de départ sont les bonnes, aurait peut être permis d'éviter le problème, car le dit programme aurait planté dès la phase de test.
En disant cela je comprend qu'on ne peut pas se permettre de tout recoder en Rust, mais tout de même, je n'ai jamais trouvé bien pratique cette façon d'accepter n'importe quoi en C en matière de gestion de mémoire, en pariant sur le fait qu'un⋅e développeur⋅e doit être parfait (impossible !), et que cela ne devrait jamais arriver.

Mais la question n'est pas de faire un catch, mais quoi faire du catch ? Si vous décider de poursuivre l'exécution alors que l'état du programme est incohérent, vous n'aurez rien résolu du problème initial et vous déplacez le problème ailleurs. S'il y a un écran bleu sous Windows, ce n'est pas parce que le noyau fonctionne mal (ou pas forcément), mais parce que le noyau est arrivé dans un état incohérent où il ne peut poursuivre son exécution sans potentiellement aggraver le problème. Un catch pour empêcher l'écran bleu ne changerait rien au fait que cela n'aurait pas du arriver dans le sens où le bug n'a pas été anticipé (sinon, il n'y aura pas de bug en fait).

Ce qui peut arriver à l'échelle du noyau peut aussi arriver à l'échelle d'un programme. Faire un catch de quelque chose d'incohérent dans le contexte, ne changera rien au fait que cela n'aurait pas du arriver. Et donc, dans ces conditions, il vaut mieux que tout plante plutôt que continuer l'exécution avec un cas non prévu. C'est tout ce que j'ai essayé de dire, et c'est pas la peine de me prendre de haut en entrant dans les détails technique du C pour noyer le poisson dans l'eau. Ce que je dis est une banalité. Votre façon de me rabaisser est intolérable.

Je n'ai pas de problème "viscéral", à vrai dire je m'en cogne de qui baise qui et de quel sexe chez lui. Ce qui me pose problème c'est vraiment le prosélytisme croissant et mal inspiré de certains dans cette communauté dont le don du sang, devant lequel ils se dégonflent après en avoir réclamé le droit et que l'EFS consente même à violer la langue pour les rameuter, n'est pas le principal problème hélas...

Je dirais que ça a démarré avec la gay-pride: Franchement, qui a envie en croisant cela dans Paris avec ses gosses de leur expliquer pourquoi 2 mecs/nanas se paluchent, ou ce que la grande folle en talons cambrée comme la vache qu'on amène au taureau a logé dans le fion?

Et ça c'était avant qu'ils ne demandent la PMA (le M c'est pour médical, rappelons le) pour toutes (sans logique vs des préférences sexuelles rendant l'affaire normalement impossible) en attendant la mère porteuse pour tous, par souçi d'égalité...

Il y a un moment ou cela pose en effet un problème qui peut devenir viscéral, mais merci de ne pas confondre cause et conséquence.

Ce qui ressortait de cette affaire au delà du problème d'écrire en français, c'est que les minorités concernées qui ont fait des pieds et des mains des décennies pour pouvoir donner, amenant sans doute à ces point-débiles-pseudo-inclusifs dans les com de l'EFS, sont plus fortiches pour réclamer des droits que pour les devoirs qui en résultent.
In-fine, comme ils ne viennent pas, l'EFS ne pouvait pas se permettre d'irriter ceux qui viennent pour quelques fio qui aiment visiblement plus râler que les piqures!
Et de ré-écrire en français lisible et même prononçable...

Du coup, que penses tu de ce petit programme de monitoring des fréquences CPU en C, écrit le nez au vent sans notes, juste avec le schéma de données en tête ?

https://github.com/TNZfr/watchfreq

Edit : Eh bé ... 22 clones du dépôt en 5 heures. :)

On peut aussi juste respecter la langue francaise, qui est déjà adaptée pour inclure TOUT LE MONDE, sans faire d'exception (contrairement à l'écriture inclusive excluante) et qui est parfaitement lisible, au lieu de tout faire pour la détruire connement.

Les personnes trop sûres d'elles au point d'être persuadées de faire un travail toujours proche de la perfection (s'ils ne la dépassent pas), c'est dans tous les domaines, pas spécifique au développment :)

Je ne supporte pas cette écriture aussi débile qu'imprononçable... Ce qui est dingue, c'est que même l'EFS s'y était mis une fois aux appels au don du sang. Apparemment, ça avait été la douche pour en avoir parlé au médecin par lequel on passe avant: Au mieux les gens venaient et demandaient quelle mouche les avait piqué au pire ils ne venaient pas. Le plus cocasse étant que ceux a qui cela s'adressait et qui a qui il était enfin permis de donner sans devoir mentir ne venaient pas plus: Ça demande des "droits" mais quand il s'agit de donner de sa personne pour les exercer y'a plus personne.

Depuis l'EFS écrit de nouveau en français. Un bilan qui vaut sans doute bien des sondages.

"Les devs que je connais sont humain·es..."

Va falloir inventer le langage de programmation inclusif, piquant les yeux à l'écrit et imprononçable à l'oral, imposant d'oublier "l'accord" qui ferait écrire "developpeur-euse" sonnant trop "develop-peureuse" et bouclerait la boucle de l'inclusif au stigmatisant!

Bon, sur le fond du problème on en revient à des préoccupations très typiques des USA: Liability menant au Foolproof (littéralement: "A l'épreuve des cons"), par conception et/ou parades/avertissements.

Les conséquences chez eux allant du "Objects in the mirror are smaller than they appear" (sans déconner!) gravé sur les rétros de bagnole à des matériels conçus pour presque tout pardonner niveau erreurs de l'utilisateur. Quand c'est trop difficile voir impossible (aviation...), cela peut mener à la faillite des constructeurs sur un seul évènement. Y'a bien que le sacro-saint flingue qui chez eux échappe au concept.

Parce qu'il n'y a pas que les dévs qui font du développement. Il y a aussi énormément de pisseurs de code (très probablement bien pus nombreux que les dévs).

Ok, continue de faire totalement abstraction de ce que j'ai dit, et du contexte de la discussion. C'est puéril, et stéril (peu importe l'organe).

Oui on est d'accord. Je dis juste que le sexe n'est pas le sujet ici.

Ce que tu as entre les jambes n'a rien à voir avec ton genre.

C'est s'adapter à son environnement avec un but. C'est de l'intelligence. C'est pas de la conscience, c'est assez basique, mais c'est de l'intelligence. Comme un chat, comme ChatGPT.

J'ai pas fait mes "petites recherches" j'ai fait mes grandes recherches et je comprends très bien le fonctionnement des transformers, et des modèles de diffusion. Notre désaccord n'est pas technique, il est philosophique.

Ha oui bien sûr où avais-je la tête.

Je suppose que les humains ne fonctionnent pas par association d'idée et qu'à chaque fois qu'on nous présente une multiplication on refait la démonstration fondamentale de la multiplication dans notre esprit.

Pour se pignoler sur "la formidable intelligence des plantes" parce qu'elles orientent leurs feuilles vers le soleil y'a du monde, par contre une machine qui peut faire une dissertation meilleure que 50% des lycéens non c'est pas intelligent, tiens on va plutôt la comparer à un philosophe professionnel comme Raphaël Enthoven. Perso j'aurais trouvé ça plus drôle si au dernier moment on avait demandé à Enthoven et à l'IA de la faire en Coréen la dissertation.

Je suis sûr que quelque part dans la jungle il y a un chimpanzé avec un égo un peu plus boursouflé que les autres, qui est convaincu que son espèce est supérieure et que si les humains ont conquis le monde c'est de la triche car ils utilisent des outils.

Une IA ne sait peut-être pas ce qu'elle dit, mais si elle est préparée pour, elle peut résoudre des problèmes mathématiques aussi bien que les meilleurs lycéens : AlphaGeometry, un champion des mathématiques, sur Numérama

Pour le moment c'est niveau Lycée, mais vu la vitesse d'évolution des IA dans quelques années il y aura probablement des théories scientifiques et/ou des démonstrations mathématiques découverte par IA.

Bah non, si Flock n'avait pas fait une non-faute, je n'aurais rien dit.

Désolé, je pensais que tu savais lire ou faire un Ctrl F (2e occurence du mot "milliard"). Voici le passage en question :

5. Nombres inférieurs à 2 : accord
Un nom précédé d’une indication chiffrée inférieure à 2 (avec virgule) reste au singulier. On écrit donc : 1,5 milliard ; 1,9 milliard, ce qui, d’ailleurs, se lira plutôt : un milliard et demi et un milliard neuf cents millions ou un milliard virgule neuf.

Donc j'admets mon erreur, on m'a mal appris quand j'étais enfant, et je n'ai pas pris la peine de vérifier si elle était juste. Et effectivement si j'avais sourcé, je m'en serais aperçu avant de poster ! Errare humanum est.

Merci Flock d'avoir fait de moi une meilleure personne

La voie prise est de réutiliser l'infrastructure de capture vidéo déjà en place et de profiter de l'avancée sur l'IA en matière de reconnaissance pour justement pouvoir gérer toutes ces fluctuations.

Le fait de ne pas pouvoir distinguer un vélo non-pliable d'un pliable n'est pas une preuve que le système ne peut pas fonctionner. Juste que le modèle de l'IA n'a pas été entraîné pour ça encore.

Tout le concept d'Amazon Prime, c'est justement la vente liée.

J'ai testé la mienne et elle est vulnérable.

De toute façon en démontant l'un des boitiers par curiosité, j'ai vu un PIC et me suis dit que c'était surement du keeloq, avec le flipper j'en ai eu le cœur net.

Par contre, comme c'est un code tournant, à chaque ouverture/fermeture avec le FlipperZero, il fallait ensuite faire autant d'ouverture/fermeture avec la télécommande pour arriver au même code...

C'est un problème bien plus global hélas causé par les vendeurs de solutions IT : faire croire aux personnes que c'est de l'informagique.

Grâce à ça, des gens croient que parce que leurs photos sont sur Google Drive, elles sont "sauvegardées", que le Cloud c'est magique ("t'as vu j'appuie et j'ai mon infra" - exposée aux 4 vents, mais ça c'est un détail), etc. OpenAI a aussi trop bullshit sur les capacités de ses produits.

Si les LLM sont puissants quand bien exploités, malheureusement trop de conneries sont dites autour. Et ce n'est pas une actualité uniquement axée sur l'aspect anxiogène du domaine qui va aider à apprendre à les appréhender intelligemment.

Ça fait partie de la panoplie d’un medium de faire parler les morts.