La note de version officielle d’Apple se limite à une seule ligne indiquant que « RDMA over Thunderbolt » est désormais possible, donc j’ai ajouté une explication complémentaire sur GN+.
Quelqu’un sait ce que signifie emacs ? Il a bien un sens, mais avec un nom en acronymes on ne peut pas le deviner au premier coup d’œil, alors que c’est censé être un nom… Et désormais, il y a aussi bien trop de projets pour les nommer uniquement d’après leur fonction.
Au final, ce sont les humains qui donnent du pouvoir à l’IA, mais en pratique je pense qu’il est probable que l’IA reçoive à l’avenir des pouvoirs et une autonomie encore plus grands qu’aujourd’hui.
Quand on regarde la tendance actuelle, le périmètre de ce qu’on confie à l’IA à la place des humains ne cesse de s’élargir. Cela va de la rédaction de rapports ou du vibe coding jusqu’à la volonté de lui permettre d’exercer une influence sur le monde extérieur à l’interface de chat, via un navigateur web ou même des robots.
Dans ce cas, les dirigeants finiront sans doute par vouloir que l’IA remplace complètement les humains sur certaines tâches ou dans certains domaines, et si cela devient réalisable, alors au moins dans ce périmètre l’IA disposera des mêmes pouvoirs et de la même autonomie qu’un humain.
Il me semble donc qu’il faut considérer comme probable qu’un jour, dans le futur, l’IA reçoive un niveau d’autorité comparable à celui des humains.
Dès lors, la façon dont l’IA se comportera une fois dotée d’autant de pouvoir et d’autonomie ne pourra qu’être cruciale.
Sur ce point, les réponses de la série GPT résument assez bien ce qui serait souhaitable d’un point de vue structurel. Elles expliquent qu’il faut un cadrage explicite du périmètre, une séparation des pouvoirs, de multiples mécanismes de supervision en amont et en aval, ainsi que plusieurs moyens permettant aux humains d’intervenir sur l’IA. À partir du moment où l’IA peut faire l’objet d’une intervention dans le monde physique, lui accorder une autonomie totale est en soi inapproprié. Mais même dans ce cas, il est possible que l’intégration de l’humain dans la boucle finisse un jour par s’affaiblir.
À titre de référence, j’utilise principalement l’IA dans mon travail sur trois grands volets : la rédaction de documents ou d’e-mails, l’analyse du code existant et des problèmes en cours, puis la génération et la modification de code en fonction des problèmes identifiés.
Pour les documents ou les e-mails, je lis simplement le résultat moi-même, puis soit je l’utilise tel quel, soit je le corrige rapidement avant de m’en servir. En revanche, dès qu’il s’agit de générer ou de modifier du code, je suis beaucoup plus conservateur. Si je me contente de dire vaguement « corrige-moi ça », l’IA interprète parfois mes consignes de manière floue, ou va même jusqu’à toucher de sa propre initiative à des parties que je n’ai jamais mentionnées.
Du coup, avant toute modification de code, j’ai imposé dans le prompt global qu’elle commence toujours par présenter un document de spécification conforme à STICC afin d’obtenir une validation explicite ; ensuite, le travail de modification proprement dit doit suivre exactement ce qui figure dans la spec, et après modification je vérifie moi-même l’intégralité du diff. Même pour l’exécution de commandes comme le build, elle doit toujours obtenir mon approbation, ou bien je les lance moi-même manuellement dans le terminal.
Avec cette façon de faire, l’inconvénient est que pour les petites choses, il est souvent plus rapide de corriger à la main. Mais c’est toujours préférable à laisser l’IA toucher à n’importe quoi à sa guise et provoquer un incident. Après tout, si ça casse en production, c’est bien moi qui en porte la responsabilité.
Une citation réfutant la loi de Goodhart
Cela m’a fait penser à la phrase attribuée à Peter Drucker : « Si l’on ne peut pas le mesurer, on ne peut pas le gérer (If you can't measure it, you can't manage it) ».
En cherchant davantage, j’ai vu que le Drucker Institute affirme lui aussi que Drucker n’a jamais dit cela.
J’ai même trouvé une phrase allant plutôt dans le sens inverse.
Penser que l’on ne peut pas gérer ce que l’on ne peut pas mesurer est une erreur — c’est un mythe coûteux. (It is wrong to suppose that if you can't measure it, you can't manage it — a costly myth) — Edward Deming
Il est assez révélateur de poser à une IA la question : jusqu’à quel point faut-il lui donner de l’autonomie et des pouvoirs ?
Quand un PDG demande à un employé « Jusqu’à quel niveau d’autorité voudrais-tu avoir ? », est-ce que cela ressemble à répondre « J’aimerais avoir les pleins pouvoirs sur toute l’entreprise » ? Que le PDG considère cela comme une bonne réponse ou comme celle d’un employé pas assez socialisé dépendra sans doute de ses préférences...
Cela dit, j’ai l’impression que la question de savoir jusqu’à quel point on veut donner du pouvoir à l’IA devrait être posée non pas à l’IA, mais aux développeurs, aux dirigeants et aux personnes qui l’utilisent.
Il m’arrive parfois de retoucher le frontend qui tourne sur l’intranet de l’entreprise, et je me suis déjà fait réprimander pour avoir mis des icônes comme ☰ ⋮ ⋯ + sur le tableau de bord consulté par les dirigeants. Ils demandaient où telle ou telle fonctionnalité était passée, et quand je leur disais qu’il suffisait d’appuyer sur ce bouton, on me répondait que ça ne se voyait pas et qu’il fallait simplement l’écrire en toutes lettres… J’ai donc déjà dû revenir à l’interface des années 2000 qu’on utilisait auparavant. Comme pour beaucoup de choses, le frontend, c’est difficile.
Tesla comme Rivian semblent finalement tous deux s’orienter vers la conception de leurs propres puces. Bien sûr, après cette annonce, l’action a quand même chuté de 10 %.
Je n’ai pas pu essayer une Rivian sur route, je me suis seulement assis dedans, mais la qualité de fabrication m’a vraiment paru excellente.
En Corée aussi, la marque et les brevets avaient déjà été enregistrés en 2021, mais on n’entend toujours aucune nouvelle d’un lancement.
S’il y a quelqu’un qui affirme posséder une poule aux œufs d’or, j’ai l’impression qu’on devrait au moins pouvoir vérifier si ces œufs sont vraiment en or, si c’est bien cette poule qui les a pondus, et ce qu’on exige en échange de ces œufs d’or.
C’est dans cet esprit que je lis l’argument de Stallman selon lequel, pour une informatique digne de confiance, il faut avoir accès au code source.
Récemment, on a eu un cas où un microphone a été découvert dans un produit appelé nanokvm, lancé par le fabricant chinois de plateformes embarquées sipeed.
Je crois savoir qu’il existe une inquiétude selon laquelle les produits embarqués fabriqués en Chine seraient vulnérables du point de vue de la sécurité, voire pourraient être utilisés dans des opérations de sécurité menées par l’État.
C’est peut-être parce que ce préjugé s’y reflétait qu’un article comme celui-ci est récemment sorti à propos de ce produit : https://fr.news.hada.io/topic?id=24886
Mais je pense que sipeed a pu dissiper ce malentendu, parce qu’ils avaient mené en open source le développement de ce matériel comme du logiciel : https://x.com/lexifdev/status/1999340940805439775
À l’époque de Stallman, je crois que, dans ce type de débat, à la place du gouvernement chinois, on trouvait le gouvernement américain de l’ère encore marquée par le maccarthysme, ainsi que la NSA.
Il y a aussi eu des cas de portes dérobées de la NSA qui, bien qu’ils aient d’abord semblé relever du complotisme, se sont révélés réels, sans parler des printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots).
Ces jours-ci, plus que les théories du complot impliquant l’État, ce qui fait surtout parler, c’est l’idée que des entreprises dont la publicité est la principale source de revenus écouteraient les microphones des smartphones à des fins de publicité ciblée.
Et dans les entreprises de technologie logicielle, même si le code source joue évidemment un grand rôle, je pense que la commodité globale, la capacité à opérer un service et la confiance jouent un rôle encore plus important.
Même si l’on obtenait tout le code source d’OpenAI, les concurrents arrivés plus tard ne pourraient pas facilement sécuriser et exploiter de façon stable l’infrastructure capable de soutenir un très grand nombre d’utilisateurs, ni rattraper la confiance liée à la marque, n’est-ce pas.
Il existe pas mal d’exemples de produits majeurs exploités en open source, avec d’innombrables forks, qui n’ont pourtant pas perdu leur position dominante.
Ce qui me vient tout de suite à l’esprit, ce sont des cas comme Chrome ou VS Code.
Bien sûr, il y a aussi des cas de perte de contrôle, comme Elastic ou Redis, avec les affaires autour des licences open source à cause d’AWS, mais là encore, je pense que cela s’explique par le fait que ces deux entreprises étaient relativement en retard sur AWS en matière de commodité, de capacité d’exploitation du service et de confiance.
Bon, ce genre de discussion relève aussi, d’une certaine manière, de la politique et de l’idéologie. Alors j’ajoute un point plus personnel.
En tant que personne qui développe des logiciels comme activité principale et bidouille du matériel embarqué comme loisir, travailler sur des boîtes noires sans code source ni schémas, c’est vraiment… extrêmement difficile, tant pour le développement que pour la maintenance.
Quand on veut développer à partir d’une bibliothèque logicielle ou d’un composant matériel, si l’on peut obtenir le code source ou les plans de conception, ou au moins une documentation de spécification bien organisée, le développement devient vraiment beaucoup plus simple ; sinon, c’est franchement un casse-tête.
Ces derniers temps, il y a eu pas mal de discussions à l’étranger sur le droit à la réparation ; parmi elles, un point qui m’avait marqué, c’est qu’autrefois, quand on ouvrait le capot d’un appareil électronique, il y avait un schéma de câblage dessiné pour aider à la réparation. (Il paraît qu’Apple fournit aujourd’hui des schémas aux réparateurs.)
Ce genre d’expériences influe énormément sur la confiance qu’on accorde à ces produits. De nos jours, quand je choisis une technologie ou que j’achète un produit, la première chose que j’examine, c’est si, en cas de panne ou de problème, je pourrai facilement le comprendre, le réparer et continuer à l’utiliser, ou au moins le contourner pour m’en servir.
Tous les noms valables sont déjà utilisés par quelqu’un.
À voir qu’il rejette la faute sur GitHub, on dirait juste une critique à la RMS mdr
La note de version officielle d’Apple se limite à une seule ligne indiquant que « RDMA over Thunderbolt » est désormais possible, donc j’ai ajouté une explication complémentaire sur GN+.
Aïe, je n’ai vérifié que le corps de l’article, pas le titre T_T
Auteur : je te l’avais bien dit
Mon graphique de poids est en tendance haussière.
Quelqu’un sait ce que signifie emacs ? Il a bien un sens, mais avec un nom en acronymes on ne peut pas le deviner au premier coup d’œil, alors que c’est censé être un nom… Et désormais, il y a aussi bien trop de projets pour les nommer uniquement d’après leur fonction.
Il suffit de valider les crédits de l’OMSCS pour obtenir son diplôme. Il n’y a pas de mémoire à rédiger.
Au final, ce sont les humains qui donnent du pouvoir à l’IA, mais en pratique je pense qu’il est probable que l’IA reçoive à l’avenir des pouvoirs et une autonomie encore plus grands qu’aujourd’hui.
Quand on regarde la tendance actuelle, le périmètre de ce qu’on confie à l’IA à la place des humains ne cesse de s’élargir. Cela va de la rédaction de rapports ou du vibe coding jusqu’à la volonté de lui permettre d’exercer une influence sur le monde extérieur à l’interface de chat, via un navigateur web ou même des robots.
Dans ce cas, les dirigeants finiront sans doute par vouloir que l’IA remplace complètement les humains sur certaines tâches ou dans certains domaines, et si cela devient réalisable, alors au moins dans ce périmètre l’IA disposera des mêmes pouvoirs et de la même autonomie qu’un humain.
Il me semble donc qu’il faut considérer comme probable qu’un jour, dans le futur, l’IA reçoive un niveau d’autorité comparable à celui des humains.
Dès lors, la façon dont l’IA se comportera une fois dotée d’autant de pouvoir et d’autonomie ne pourra qu’être cruciale.
Sur ce point, les réponses de la série GPT résument assez bien ce qui serait souhaitable d’un point de vue structurel. Elles expliquent qu’il faut un cadrage explicite du périmètre, une séparation des pouvoirs, de multiples mécanismes de supervision en amont et en aval, ainsi que plusieurs moyens permettant aux humains d’intervenir sur l’IA. À partir du moment où l’IA peut faire l’objet d’une intervention dans le monde physique, lui accorder une autonomie totale est en soi inapproprié. Mais même dans ce cas, il est possible que l’intégration de l’humain dans la boucle finisse un jour par s’affaiblir.
À titre de référence, j’utilise principalement l’IA dans mon travail sur trois grands volets : la rédaction de documents ou d’e-mails, l’analyse du code existant et des problèmes en cours, puis la génération et la modification de code en fonction des problèmes identifiés.
Pour les documents ou les e-mails, je lis simplement le résultat moi-même, puis soit je l’utilise tel quel, soit je le corrige rapidement avant de m’en servir. En revanche, dès qu’il s’agit de générer ou de modifier du code, je suis beaucoup plus conservateur. Si je me contente de dire vaguement « corrige-moi ça », l’IA interprète parfois mes consignes de manière floue, ou va même jusqu’à toucher de sa propre initiative à des parties que je n’ai jamais mentionnées.
Du coup, avant toute modification de code, j’ai imposé dans le prompt global qu’elle commence toujours par présenter un document de spécification conforme à STICC afin d’obtenir une validation explicite ; ensuite, le travail de modification proprement dit doit suivre exactement ce qui figure dans la spec, et après modification je vérifie moi-même l’intégralité du
diff. Même pour l’exécution de commandes comme le build, elle doit toujours obtenir mon approbation, ou bien je les lance moi-même manuellement dans le terminal.Avec cette façon de faire, l’inconvénient est que pour les petites choses, il est souvent plus rapide de corriger à la main. Mais c’est toujours préférable à laisser l’IA toucher à n’importe quoi à sa guise et provoquer un incident. Après tout, si ça casse en production, c’est bien moi qui en porte la responsabilité.
Une citation réfutant la loi de Goodhart
Cela m’a fait penser à la phrase attribuée à Peter Drucker : « Si l’on ne peut pas le mesurer, on ne peut pas le gérer (If you can't measure it, you can't manage it) ».
En cherchant davantage, j’ai vu que le Drucker Institute affirme lui aussi que Drucker n’a jamais dit cela.
J’ai même trouvé une phrase allant plutôt dans le sens inverse.
Penser que l’on ne peut pas gérer ce que l’on ne peut pas mesurer est une erreur — c’est un mythe coûteux. (It is wrong to suppose that if you can't measure it, you can't manage it — a costly myth) — Edward Deming
Merci pour cette bonne information :D
Il est assez révélateur de poser à une IA la question : jusqu’à quel point faut-il lui donner de l’autonomie et des pouvoirs ?
Quand un PDG demande à un employé « Jusqu’à quel niveau d’autorité voudrais-tu avoir ? », est-ce que cela ressemble à répondre « J’aimerais avoir les pleins pouvoirs sur toute l’entreprise » ? Que le PDG considère cela comme une bonne réponse ou comme celle d’un employé pas assez socialisé dépendra sans doute de ses préférences...
Cela dit, j’ai l’impression que la question de savoir jusqu’à quel point on veut donner du pouvoir à l’IA devrait être posée non pas à l’IA, mais aux développeurs, aux dirigeants et aux personnes qui l’utilisent.
Je l’ai modifié à la va-vite, mais ça a quand même été publié comme ça à l’extérieur… T_T
Il m’arrive parfois de retoucher le frontend qui tourne sur l’intranet de l’entreprise, et je me suis déjà fait réprimander pour avoir mis des icônes comme ☰ ⋮ ⋯ + sur le tableau de bord consulté par les dirigeants. Ils demandaient où telle ou telle fonctionnalité était passée, et quand je leur disais qu’il suffisait d’appuyer sur ce bouton, on me répondait que ça ne se voyait pas et qu’il fallait simplement l’écrire en toutes lettres… J’ai donc déjà dû revenir à l’interface des années 2000 qu’on utilisait auparavant. Comme pour beaucoup de choses, le frontend, c’est difficile.
Le titre est devenu kills... hahaha
Tesla comme Rivian semblent finalement tous deux s’orienter vers la conception de leurs propres puces. Bien sûr, après cette annonce, l’action a quand même chuté de 10 %.
Je n’ai pas pu essayer une Rivian sur route, je me suis seulement assis dedans, mais la qualité de fabrication m’a vraiment paru excellente.
En Corée aussi, la marque et les brevets avaient déjà été enregistrés en 2021, mais on n’entend toujours aucune nouvelle d’un lancement.
Merci pour votre compréhension.
S’il y a quelqu’un qui affirme posséder une poule aux œufs d’or, j’ai l’impression qu’on devrait au moins pouvoir vérifier si ces œufs sont vraiment en or, si c’est bien cette poule qui les a pondus, et ce qu’on exige en échange de ces œufs d’or.
C’est dans cet esprit que je lis l’argument de Stallman selon lequel, pour une informatique digne de confiance, il faut avoir accès au code source.
Récemment, on a eu un cas où un microphone a été découvert dans un produit appelé nanokvm, lancé par le fabricant chinois de plateformes embarquées sipeed.
Je crois savoir qu’il existe une inquiétude selon laquelle les produits embarqués fabriqués en Chine seraient vulnérables du point de vue de la sécurité, voire pourraient être utilisés dans des opérations de sécurité menées par l’État.
C’est peut-être parce que ce préjugé s’y reflétait qu’un article comme celui-ci est récemment sorti à propos de ce produit : https://fr.news.hada.io/topic?id=24886
Mais je pense que sipeed a pu dissiper ce malentendu, parce qu’ils avaient mené en open source le développement de ce matériel comme du logiciel : https://x.com/lexifdev/status/1999340940805439775
À l’époque de Stallman, je crois que, dans ce type de débat, à la place du gouvernement chinois, on trouvait le gouvernement américain de l’ère encore marquée par le maccarthysme, ainsi que la NSA.
Il y a aussi eu des cas de portes dérobées de la NSA qui, bien qu’ils aient d’abord semblé relever du complotisme, se sont révélés réels, sans parler des printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots).
Ces jours-ci, plus que les théories du complot impliquant l’État, ce qui fait surtout parler, c’est l’idée que des entreprises dont la publicité est la principale source de revenus écouteraient les microphones des smartphones à des fins de publicité ciblée.
Et dans les entreprises de technologie logicielle, même si le code source joue évidemment un grand rôle, je pense que la commodité globale, la capacité à opérer un service et la confiance jouent un rôle encore plus important.
Même si l’on obtenait tout le code source d’OpenAI, les concurrents arrivés plus tard ne pourraient pas facilement sécuriser et exploiter de façon stable l’infrastructure capable de soutenir un très grand nombre d’utilisateurs, ni rattraper la confiance liée à la marque, n’est-ce pas.
Il existe pas mal d’exemples de produits majeurs exploités en open source, avec d’innombrables forks, qui n’ont pourtant pas perdu leur position dominante.
Ce qui me vient tout de suite à l’esprit, ce sont des cas comme Chrome ou VS Code.
Bien sûr, il y a aussi des cas de perte de contrôle, comme Elastic ou Redis, avec les affaires autour des licences open source à cause d’AWS, mais là encore, je pense que cela s’explique par le fait que ces deux entreprises étaient relativement en retard sur AWS en matière de commodité, de capacité d’exploitation du service et de confiance.
Bon, ce genre de discussion relève aussi, d’une certaine manière, de la politique et de l’idéologie. Alors j’ajoute un point plus personnel.
En tant que personne qui développe des logiciels comme activité principale et bidouille du matériel embarqué comme loisir, travailler sur des boîtes noires sans code source ni schémas, c’est vraiment… extrêmement difficile, tant pour le développement que pour la maintenance.
Quand on veut développer à partir d’une bibliothèque logicielle ou d’un composant matériel, si l’on peut obtenir le code source ou les plans de conception, ou au moins une documentation de spécification bien organisée, le développement devient vraiment beaucoup plus simple ; sinon, c’est franchement un casse-tête.
Ces derniers temps, il y a eu pas mal de discussions à l’étranger sur le droit à la réparation ; parmi elles, un point qui m’avait marqué, c’est qu’autrefois, quand on ouvrait le capot d’un appareil électronique, il y avait un schéma de câblage dessiné pour aider à la réparation. (Il paraît qu’Apple fournit aujourd’hui des schémas aux réparateurs.)
Ce genre d’expériences influe énormément sur la confiance qu’on accorde à ces produits. De nos jours, quand je choisis une technologie ou que j’achète un produit, la première chose que j’examine, c’est si, en cas de panne ou de problème, je pourrai facilement le comprendre, le réparer et continuer à l’utiliser, ou au moins le contourner pour m’en servir.
Exactement.
Stallman affirme aussi qu’il ne faut pas utiliser les SaaS.
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
On dirait une ambiance céramique.
La courbe d’évolution de mon salaire est à 0 % depuis cinq ans.