La lettre hebdomadaire de Café IA

Lire en ligne. 

Bonjour à tous.tes,

 

On vous a manqué ? Nous revoilà !

Nous sommes le jeudi 30 avril 2026. Au menu de cette 31e édition de la lettre Café IA : orchestrer les agents, orchestrer le monde ✦ Oh, venez voir le blog de Café IA est ouvert ! 👀 ✦ La ressource de la semaine : Comprendre comment l’IA apprend à gagner ✦ Et comme chaque semaine, retrouvez toute l’actualité de la communauté Cafés IA …

 

Bonne lecture !

 
 
 

Orchester les agents, orchestrer le monde   

Hubert Guillaud

Il y a six mois, la plupart des développeurs travaillaient avec un seul assistant IA dans une boucle synchrone étroite, raconte l’ingénieur de Google, Addy Osmani. « Vous saisissiez une invite, attendiez, examiniez le résultat, donniez un retour, et ainsi de suite. Vos possibilités étaient limitées par la taille de cette unique fenêtre de contexte. Le fil de conversation constituait votre espace de travail. Aujourd'hui, les développeurs les plus productifs coordonnent plusieurs agents fonctionnant de manière asynchrone – chacun avec son propre contexte, son propre espace de fichiers et son propre domaine de responsabilité – tandis que le développeur orchestre le tout. Le code source devient un espace de création, et non plus un fil de discussion. On passe ainsi du rôle de chef d'orchestre (un musicien, un guidage en temps réel) à celui d'orchestrateur (un ensemble complet, une coordination asynchrone). » 

 

Dans une présentation qu’il a donnée à la conférence AI CodeCon O’Reilly, Osmani détaille 8 niveaux de maîtrise du codage assisté par agents (tirée d’une analyse proposée par Steve Yegge).

  • Le niveau 1, où le développeur n’utilise pas l’IA.
  • Le niveau 2, où le développeur approuve chaque modification en ayant un contrôle manuel total.
  • Le niveau 3, le mode Yolo, où l’agent s’exécute librement dans l’environnement de développement. C’est le niveau où la confiance s’installe.
  • Le niveau 4, c’est le temps où la conversation prend le dessus. Vous cessez d’examiner chaque différence, vous observez ce que fait l’agent et vous vous concentrez sur son pilotage.
  • Le niveau 5, c’est le temps où l’on donne la priorité aux agents sur l’environnement de développement qui ne sert qu’à consulter le code.
  • Le niveau 6, c’est le niveau où l'on s'ennuie à attendre et où on lance d’autres agents et où l’on jongle entre les flux.
  • Le niveau 7, c’est celui où vous gérez manuellement plus de 10 agents et où vous finissez par envoyer un contexte au mauvais agent.
  • Le niveau 8, c’est celui où vous créez votre propre orchestrateur. Vous écrivez vous-même la couche de coordination en créant et gérant les agents par programmation.

Ces différents niveaux sont donc des étapes progressives d’adaptation du développeur aux agents. « La plupart des développeurs sont bloqués aux niveaux 3 et 4. Le niveau d'orchestration commence au niveau 6 et requiert des compétences fondamentalement différentes de celles nécessaires pour atteindre le niveau 5. » Dans le modèle du chef d’orchestre, vous guidez un seul agent d’IA en temps réel. Il est synchrone, séquentiel, et votre fenêtre de contexte est fixe. Dans le modèle de l’orchestrateur, vous coordonnez un ensemble complet. Plusieurs agents, chacun avec sa propre fenêtre de contexte, travaillent de manière asynchrone. Vous planifiez le travail, l’assignez et effectuez des vérifications régulières. « Tout comme pour la gestion d'une véritable équipe, vous avez désormais besoin de compétences différentes : des spécifications claires, une décomposition des tâches et une vérification des résultats plutôt que d'écrire vous-même le code.»

 

Un agent unique se révèle vite surchargé par les limites contextuelles. Il gère tout, sans être spécialisé, au risque d'être moins bon. Et enfin, il manque de coordination si vous créez un agent auxiliaire avec lequel il ne peut communiquer ou partager une liste de tâches. L’architecture multi-agents a d’autres avantages, permettant de développer par exemple le frontend, le backend et les tests. Cela permet de les spécialiser, de sécuriser et surtout de les faire s’améliorer entre eux.

 

La suite de l’article d’Addy Osmani donne des exemples pour développeurs, pour passer d’un niveau à l’autre et prendre confiance, étape par étape. On en réservera la lecture à ceux qui souhaitent progresser.

 

Il y rappelle néanmoins, que, comme nous le disions il y a peu, « le goulot d'étranglement n'est plus la génération, mais la vérification ». « Les agents peuvent produire des résultats impressionnants à une vitesse incroyable. Le plus difficile est de savoir avec certitude si ces résultats sont corrects. Les tests réussis avant une modification ne garantissent pas la détection des régressions induites par cette modification. Les agents peuvent écrire des tests techniquement valides, mais qui passent à côté de cas importants. Les limitations de la fenêtre de contexte font que les agents travaillant sur de vastes bases de code peuvent manquer des contraintes importantes hors de leurs champs d’action. Et les environnements instables, qu'un développeur isolé rencontre comme un cas particulier agaçant, deviennent des blocages systémiques lorsque quarante agents rencontrent simultanément le même test instable. Tant que l'infrastructure de vérification n'aura pas rattrapé les capacités de génération, la vérification humaine n'est pas une surcharge optionnelle. C'est le système de sécurité. La bonne réponse face à des résultats impressionnants produits par les agents n'est pas de leur faire confiance simplement parce qu'ils semblent corrects. Il faut avoir la compréhension architecturale et la discipline de test nécessaires pour les évaluer rigoureusement. » 

 

La discipline est ce qui rend ce système efficace, rappelle l’ingénieur. « Le goulot d'étranglement humain était une caractéristique, et non un bug. À un rythme humain, les erreurs s'accumulent lentement et la difficulté à les corriger rapidement incite à la correction. Avec une armée d'agents, les petites erreurs s'accumulent à une vitesse telle qu'il devient impossible de les détecter. Lorsque des humains écrivent du code lentement, les conséquences se font sentir rapidement. Un test échoue, une revue de code révèle un problème, on remarque une duplication… :  la difficulté est immédiate, on corrige donc au fur et à mesure. Avec une armée d'agents orchestrée, il n'y a pas de goulot d'étranglement naturel. Les petites erreurs anodines – une mauvaise hygiène de code par-ci, une duplication par-là, une abstraction inutile – s'accumulent à un rythme insoutenable. On est sorti de la boucle, on ne ressent donc les conséquences que lorsqu'il est trop tard. Puis un jour, on essaie d'ajouter une fonctionnalité, et l'architecture ne le permet pas. Vos tests sont tout aussi peu fiables, car ils ont également été écrits par des agents. C'est pourquoi chaque contrôle qualité est essentiel. » Pour l’ingénieur, il faut approuver les propositions, gérer le budget de tokens, relire. Sans ces étapes, vous risquez de vous retrouver dans une impasse en programmant de manière automatisée. Il faut déléguer les tâches, pas le jugement.

 

« Laissez les agents gérer les tâches circonscrites avec des critères de réussite/échec clairs, le code standard, les migrations et la structure des tests. Gardez pour vous l'architecture, les décisions relatives aux fonctionnalités à ne pas implémenter, les revues de code contextualisées et le savoir-faire nécessaire à la conception de systèmes de qualité. Les agents excellent dans tout ce qui dispose d'une fonction d'évaluation précise, leur permettant de mesurer leur propre travail. Ils sont particulièrement performants en matière de code standard, de migrations, de structure des tests et d'exploration d'approches que vous n'auriez jamais le temps d'essayer manuellement. Gardez pour vous : l'architecture et la conception, la décision de ce qu'il ne faut PAS développer (dire non est une fonctionnalité dont les agents ne disposent pas), et la vérification des résultats des agents dans le contexte complet du système (les agents n'ont qu'une vue locale). Développez moins de fonctionnalités, mais les bonnes. La vitesse de génération de code est un leurre. Prenez votre temps pour conserver une bonne compréhension. Car si vous perdez la compréhension de votre propre système, vous perdez la capacité de le réparer, de l'étendre, voire même de savoir quand il dysfonctionne ».

 

La spécification la plus précise est un levier. « Lorsque vous orchestrez cinquante agents en parallèle, une pensée vague ne vous ralentit pas seulement, elle multiplie les erreurs. Des exigences ambiguës se propagent à travers des dizaines d'exécutions parallèles. La différence entre un résultat médiocre et un résultat exceptionnel repose presque entièrement sur la qualité de votre spécification. Une spécification vague multiplie les erreurs dans toute la flotte. Une spécification précise – avec une architecture claire, des limites d'intégration, des cas limites et des invariants – se traduit par des implémentations précises à tous les niveaux. La spécification n'est plus une simple consigne. Elle explicite la réflexion produite ». C'est pourquoi les développeurs expérimentés tirent davantage profit de ces outils que les moins expérimentés.

 

Ces bons conseils et pratiques montrent en creux les limites de ces outils, notamment leur capacité à produire des défaillances. Et le haut niveau de maîtrise qu’il faut détenir pour les exploiter au mieux.

 

Pour Addy Osmani, le développeur doit adopter le modèle de l’usine. « Vous ne vous contentez plus d'écrire du code : vous construisez l'usine qui construit votre logiciel. Cette usine possède une chaîne de production : Planification, Création, Surveillance, Vérification, Intégration, Rétroaction. Une usine dispose d'un contrôle qualité. Une usine dispose d'une documentation des processus. Une usine a des entrées qui doivent être spécifiées avec précision, sinon les sorties seront erronées. Une usine s'arrête lorsque l'environnement est instable. Toutes ces propriétés correspondent directement au développement logiciel multi-agents ».

 

Pour le dire autrement, avec l’IA agentique, le développeur n’est plus celui qui fait son petit code qui s’intègre dans l’architecture globale. Il n’est plus le prolétaire du code, mais est promu directeur d’usine, entouré d’agents dont il doit cadrer la moindre action. Ça ressemble à la fois à une promotion… et à une responsabilité démesurée.

 

De l’usine logicielle… à la Dark Factory   

 

Sur son blog, le développeur et multi-entrepreneur, Dan Shapiro (qui travaille également pour le Wharton Generative AI Labs avec Ethan Mollick), ne propose quant à lui que 5 niveaux d’automatisation du développement.

  • Le niveau 0, là, consiste seulement à utiliser l’IA (l’idée qu’on ne l’utilise pas semble être devenue déjà impensable).
  • Au niveau 1, vous écrivez le code important, mais vous déléguez des tâches spécifiques et discrètes à votre assistant IA. Vous constatez des gains de vitesse, mais votre travail reste le même. Vous avancez toujours à la vitesse à laquelle vous tapez.
  • Au niveau 2, c'est comme si vous étiez en pilotage automatique sur l'autoroute. En tant que développeur, vous vous sentez libre. Vous avez un collègue junior à qui confier toutes les tâches ennuyeuses. C’est là que se trouvent actuellement 90 % des développeurs « natifs de l’IA ». Vous collaborez avec l’IA comme avec un collègue. Vous entrez dans un état de concentration intense ; votre productivité est sans précédent. Vous n’utilisez pas de messagerie instantanée, vous exploitez pleinement un outil de codage natif de l’IA. Mais voici le danger : le niveau 2, et tous les suivants, donnent l’impression d’avoir atteint le sommet. Or, ce n’est pas le cas.
  • Le niveau 3 est comparable à une voiture autonome Waymo avec un conducteur de sécurité. Vous n’êtes plus un développeur senior ; ce rôle est dévolu à votre IA. Vous êtes… un gestionnaire. Vous êtes l’humain au cœur de la boucle. Votre agent de codage jongle constamment avec plusieurs onglets. Vous passez vos journées à relire du code. Des tonnes de code. Votre vie se résume aux différences de code. Pour beaucoup, c’est comme si la situation avait empiré.
  • Le niveau 4 est comparable à un robotaxi : pendant qu’il conduit, vous pouvez faire autre chose. Vous n’êtes plus un développeur. Vous n’êtes plus non plus un responsable de développement. Vous êtes désormais devenu ce que vous détestiez : un gestionnaire produit. Vous rédigez un cahier des charges. Vous le contestez. Vous développez des compétences (pour Claude Code, car la plupart des personnes de niveau 4 semblent s'y orienter). Vous établissez des plannings. Vous les révisez. Puis vous partez 12 heures et vérifiez la réussite des tests.
  • Au niveau 5, ce n'est plus vraiment une voiture. Vous n'exécutez plus vraiment le logiciel de quelqu'un d'autre. Et votre processus logiciel n'est plus vraiment un processus logiciel. C'est une boîte noire qui transforme les spécifications en logiciel.

Pour parler de ce niveau 5, Shapiro l’appelle le niveau Dark Factory, l’usine sombre, en hommage à une usine où des robots fabriquent des robots, sans que les humains ne puissent y accéder (mais qui évoque également le moment de Dark Enlightenment, ce moment réactionnaire de la Tech). « C 'est un lieu où les humains ne sont ni nécessaires ni bienvenus ». Ces usines sombres, Shapiro les évoque encore dans un autre billet. Il les définit comme des moteurs qui transforment des spécifications en logiciels opérationnels. Shapiro a même développé des instructions pour faciliter le travail des logiciels codeurs. Sur son blog, le développeur Simon Willson, expliquait que l’équipe IA de StrongDM, une entreprise spécialisée dans la sécurité informatique, s’est également lancée dans le développement d’usines logicielles, en imposant une surprenante double règle, allant à l’encontre de celles qu’on entend habituellement : « Le code ne doit pas être écrit par des humains. Le code ne doit pas être relu par des humains.» C’est également le titre d’un billet de Shapiro. Autrement dit, le but de l’usine logicielle semble consister à extraire totalement l’humain de la boucle, jusqu’à la vérification même du code produit. Elle réanime, comme le rappelle le développeur Ivan Turkovic, cette promesse sans cesse répétée dans l’histoire du logiciel, celle de simplifier leur création, de la rendre moins coûteuse et, à terme, d'éliminer complètement le besoin de programmeurs. Si les progrès réalisés par les modèles de langage sont réels et impressionnants, « le défi fondamental demeure inchangé : traduire l'intention humaine en un logiciel correct, efficace, maintenable et sécurisé est difficile.» Un logiciel n’est pas que du code, rappelle-t-il. « La difficulté du développement logiciel n'a jamais été d'écrire du code. Elle a toujours consisté à déterminer précisément ce que le logiciel doit faire et à s'assurer qu'il le fait effectivement en toutes circonstances. C'est pourquoi les langages de spécification et la génération automatique de code échouent systématiquement à éliminer les programmeurs : ils ne font que déplacer la complexité du code vers la spécification, et la spécification est au moins aussi difficile. De plus, un logiciel s'inscrit dans un écosystème. Il doit s'intégrer à d'autres logiciels, s'adapter à l'évolution des exigences, fonctionner sur des plateformes en constante évolution et répondre aux besoins changeants des utilisateurs. Maintenir et faire évoluer un logiciel au fil du temps exige une compréhension qui dépasse le cadre de tout langage de spécification ou outil de génération. Enfin, un logiciel reflète les choix humains en matière de compromis : performance contre maintenabilité, sécurité contre convivialité, flexibilité contre simplicité. Ces décisions requièrent un jugement qui ne peut être automatisé car il dépend du contexte, des priorités et des valeurs qui varient selon les situations. »

 

Shapiro raconte que c’est en allant voir Justin McCarthy de StrongDM qu’il a saisi la puissance du développement agentique. Notamment, lorsqu’il a vu sur son écran un tableur qui ressemblait totalement à Google Sheets, sauf que la barre d’adresse affichait « localhost ». C’était le cas de plein d’autres logiciels qu’utilisaient les développeurs de StrongDM, comme Slack, exécuté en local. En fait McCarthy avait utilisé ses agents codeurs pour recréer ces logiciels afin de pouvoir les exécuter sur son ordinateur. Les cloner, les adapter… contourner leurs limites. Marquant par là la fin du pouvoir de ceux qui les orchestrent.

 

Pour Justin McCarthy, les règles sont désormais simples, explique Shapiro : « Si l'on veut avancer vite, l’humain n'est plus la personne la plus qualifiée pour écrire du code. C'est l'IA qui écrit le code. Deuxièmement, on réalise que si l'on n'écrit pas le code et que l'on continue à examiner chaque demande de fusion, on constitue le goulot d'étranglement. Il faut donc aussi arrêter de lire le code. Troisièmement, on comprend que cela engendre une montagne de problèmes terrifiants. Si personne n'écrit de code, qui le comprend ? Si personne ne le lit, comment savoir s'il fonctionne ? Comment savoir s'il s'améliore au lieu de se dégrader ? Enfin – et c'est là que ça prend un peu de temps à assimiler – vous réalisez que résoudre ces problèmes est désormais votre véritable travail. Voilà. C'est tout. C'est comme ça qu'on construit une usine à logiciels.»

 

L'expérience de StrongDM illustre ce qui se produit lorsque le développement logiciel devient un moyen plutôt qu'une fin, conclut Shapiro. Il consiste à tout transformer en compilateur – non pas un compilateur qui transforme le BASIC en code machine, mais un compilateur qui transforme les problèmes en solutions. « Notre rôle est de maintenir le flux d'idées et la production en continu. »

 

Mais les implications peuvent être bien plus terribles, comme le montre un article de 404 media qui évoque un site satirique, mais parfaitement fonctionnel : Malus.sh. Le site propose de cloner des logiciels libres pour pouvoir les redistribuer sans mentionner les développeurs originaux. « Il est désormais plus facile que jamais de demander à des outils d'IA de produire des logiciels fonctionnellement identiques à des projets open source existants, logiciels qui, selon certains, sont entièrement développés de toutes pièces et constituent donc des œuvres originales pouvant s'affranchir des licences de droits d'auteur » (on pourrait aussi estimer que ces logiciels produits par l’IA sont intrinsèquement des produits dérivés voire des copies parasites… ce que le droit va devoir trancher rapidement).

 

Ce que Malus.sh illustre très bien, c’est combien l’IA générative s’apprête à recomposer le monde logiciel. La question n’est déjà plus de savoir si les logiciels de demain seront artisanaux ou industriels. Mais d’interroger les formes de réappropriations que ces outils dessinent. 

 

Reste, souligne Shapiro, que ces changements rapides vont avoir des effets profonds. Selon lui, nous entrons dans une période de déflation technique : l’IA fait baisser les coûts du développement logiciel. Le problème, lorsqu’il y a déflation, c’est que c’est une spirale difficile à arrêter. Le développement logiciel coûte moins cher et les entreprises n’investissent pas car elles attendent que les prix baissent encore. Dans cette situation, la dette technique, c’est-à-dire le temps passé à améliorer le produit plutôt qu’à développer des fonctionnalités, s'accroît. La correction du code est repoussée, et c’est même un investissement à terme puisque cette correction sera moins chère demain qu’elle n’est aujourd’hui. Mais la déflation technique risque également de faire augmenter la dette technique jusqu’à saturation. Bref, ça va plus vite. Le productivisme bat son plein. Mais cela ne signifie pas que la productivité, elle, va revenir… 

 

Avec les systèmes capables de programmer, la Silicon Valley estime désormais que les machines vont être capables de s’auto-améliorer, expliquent Matteo Wong et Lila Shroff pour The Atlantic. Dario Amodei, PDG d'Anthropic, estime que les outils de programmation accélèrent les flux de travail globaux de son entreprise de 15 à 20 %. Mais lorsque Anthropic affirme que Claude écrit la quasi-totalité de son code, on ignore le niveau de supervision humaine requis. Au vu de la rapidité des progrès récents en IA, Eli Lifland, chercheur au sein du projet AI Futures, prévoit que la recherche et le développement en IA pourraient être entièrement automatisés d'ici 2032 Mais entre l’automatisation de la programmation et celle de la recherche en IA, il y a un pas que les promoteurs de l’IA franchissent allègrement. En attendant, les progrès de l’auto-amélioration récursive sont un moyen de renouveler le  marketing et de surenchérir sur ses promesses. L’agentivité est le moyen de promettre à nouveau l’automatisation, quelles que soient ses conséquences. 

 

De quoi l’agentivité est-elle le nom ?   

 

Dans le New York Times, le journaliste Nitsuh Abebe se pose une bonne question : que signifie l’injonction à l’agentivité actuelle ? « Le monde de la tech est actuellement saturé par le concept d'agentivité ». Et cette réaffirmation du pouvoir d’agir à l’heure où nous sommes saturés de contenus génératifs et d’outils qui souhaitent agir à notre place, paraît comme une contradiction insoluble. C’est un peu comme si on nous demandait d’être plus actif dans un monde où nos possibilités d’actions se réduisent, puisque les machines se mettent elles-mêmes à agir…

 

L’injonction à l’agentivité appelle à agir avec assurance, plutôt que de suivre le mouvement, comme si chacun d’entre nous avait encore une capacité à façonner les résultats des machines. C’est pourtant exactement ce que répètent les innombrables conseils à devenir orchestrateurs d’innombrables agents travaillant pour nous. Comme si, à l’heure où notre capacité à agir se réduit, nous étions sommés d’être encore plus proactifs, d’exercer notre pouvoir, notre libre-arbitre, à maîtriser notre destin par devers l’adversité et pendant qu’il est encore temps. Derrière cet hymne à agir, s’exprime d’abord « des fantasmes de puissance égocentriques endémiques à la culture technologique ». Mais si on en appelle tant à l’agentivité humaine, c’est assurément parce que l’industrie de la tech nous sature de l’agentivité de l’IA, c’est-à-dire de la capacité de programmes à agir de manière autonome. Nous voici désormais dans l’ère de la programmation agentique, du commerce agentique, des rencontres agentiques… où tout ce que l’on fait sur un ordinateur pourrait être fait par un ordinateur. C’est un peu comme si notre agentivité bien humaine devait s'affirmer plus encore pour résister à la concurrence de celle des machines. 

 

« La plupart des Américains restent plus attachés à une autre signification du mot « agent ». Nous sommes habitués à l'agent comme représentant — quelqu'un qui agit au nom de quelqu'un. Les agents artistiques négocient des contrats pour les acteurs, les écrivains, les mannequins. Les agents de voyages réservent des forfaits vacances pour les groupes de touristes. L’étymologie du mot recèle ces deux sens : l’agent comme acteur, certes, mais aussi comme défenseur, instrument, émissaire. Cette double signification est incroyablement pratique pour le secteur technologique. On pourrait croire que les modèles d’IA « agentiques » sont censés nous assister, même lorsque ceux qui emploient ce terme se vantent que leurs modèles fonctionnent parfaitement sans nous. C’est précisément cette dynamique qui semble obséder certains des individus les plus avides d’autonomie. Une prédiction revient souvent chez ceux qui espèrent surpasser leurs pairs: les modèles d’IA, disent-ils, finiront par fournir tous les efforts, la formation et l’expertise qui, historiquement, ont empêché les humains d’agir. Une fois tous ces désagréments écartés, la seule chose qui distinguera les gagnants des perdants sera la motivation pure à agir, l'ambition brute de faire quelque chose – une action audacieuse et sans faille. »

 

Pour répondre à l’agentivité des machines, nous devons nous-mêmes être toujours plus agentiques, comme pour répondre au productivisme sans répit des machines, nous devons être encore plus productif. Pour répondre à l'éblouissement des machines, nous devons être encore plus éblouissants en retour ! « À l'ère de l'IA, devenir un individu extrêmement motivé est un atout majeur » ; « Avec l'avènement de l'IA générale, la motivation sera essentielle » ; « À l'ère de l'IA, devenez un individu "motivé" pour réussir ! Découvrez comment le travail évolue avec les agents IA. Ne vous laissez pas distancer ! », répètent les mantras actuels. Seule votre motivation et votre volonté exceptionnelles compteront ; tout le reste pourra être géré, comme par magie, au cœur d'un immense centre de données.

 

Reste à savoir par quoi nous pourrons encore être motivés quand nous serons totalement dépossédés.

 
 

 📆Agenda et actualités de Café IA 

 
 

Du 18 au 24 mai 2026, la Semaine de l’IA pour Tous se déploie partout en France. À l’approche du lancement, c’est le bon moment pour annoncer et valoriser vos événements.

Vous organisez un Café IA, un atelier, une projection, une conférence ou un autre temps d’échange autour de l’IA ? Tous les formats ont leur place dans cette dynamique, dès lors qu’ils permettent de sensibiliser largement aux enjeux de l’intelligence artificielle.

N’attendez pas pour ajouter votre événement sur la cartographie nationale. Plus de 450 initiatives sont déjà annoncées : à votre tour, venez rejoindre la programmation nationale en référençant votre événement.

 

🎉 Le blog est ouvert

 
 

Vous allez pouvoir désormais retrouver en ligne les ressources, éditos et meilleurs articles (et leurs formidables illustrations) de la lettre Café IA sur le blog de Café IA .Une forme de complément aux ressources pédagogiques que nous avons publiées sur l’environnement, le travail, la désinformation et l’histoire de l’IA… qui permettent de faire vivre les questions que posent les évolutions de l’IA, de les prolonger, de continuer à questionner les enjeux et effets de l’IA sur la société.

Utilisez les comme tous les autres outils que propose Café IA : des outils à partager pour débattre des impacts de l’IA dans nos vies. 

 

📰 Ce que Café IA fait à la société

 

Pour le magazine Paroles d’élus, Cécile Ravaux, Directrice de la mission Café IA explique les enjeux de la mission et revient sur les apports de la démarche : « Café IA crée un temps d’échange pour écouter les gens, débattre en toute bienveillance. Lors de ces ateliers, on utilise très peu d’ordinateurs. On privilégie les jeux, les ateliers d’écriture comme les Mikrodystopies, les formats qui permettent d’aborder les enjeux éthiques, environnementaux ou sécuritaires de l’IA de façon ludique.

 

Ce qui est frappant, c’est que les participants se rendent compte qu’ils se posent tous les mêmes questions ; sur les deepfakes, la désinformation, la protection des données personnelles. Rien que ce constat crée une vraie prise de conscience collective. »

 

Un Café IA réussi ? « C’est un café où les gens ne veulent pas partir. Et c’est ce qui se passe tout le temps. On limite les sessions à vingt participants maximum, ce qui favorise un échange authentique. Les gens se rendent compte que leurs craintes sont partagées, que leurs questions sont légitimes. »

 

☕ Les Cafés IA à venir

 

Les Cafés IA de cette semaine. Participez ! 

  • Le 30 avril à Bordeaux, un Café IA propose un moment d’échange autour du numérique et de l’intelligence artificielle.
  • Le 30 avril à Saint-Herblain, le Café IA organisé par AVISIA Ouest invite à rendre l’IA plus intelligible, éthique et accessible à tous. Gratuit, ouvert à tous, confirmation par mail : grohr@avisia.fr
  • Le 30 avril au Gros-Morne, un Café IA au Cercle Littéraire et Artistique propose d’échanger sur l’histoire, le fonctionnement et les enjeux de l’intelligence artificielle.
  • Le 30 avril à Montbazens, Qués I.A. co ? propose une présentation interactive pour mieux comprendre l’IA, ses enjeux et la place qu’on souhaite lui laisser dans nos vies.
  • Le 2 mai à Claye-Souilly, un Café IA ouvre un échange sur les enjeux clés de l’IA : emploi, éducation et transformations à venir.
  • Le 4 mai à Nice, Mikro-utopie, mikro-dystopie, mikro-poésie… propose un Café IA littéraire pour imaginer, écrire et discuter autour de l’impact de l’IA sur notre futur.
  • Le 5 mai à Beauvoir-sur-Mer, un Café IA propose un moment d’échange convivial autour du numérique et de l’intelligence artificielle.
  • Le 5 mai à Saint-Sébastien-sur-Loire, un Café IA : la bataille de l’IA invite à découvrir un jeu de cartes collaboratif pour explorer les promesses et les limites de l’intelligence artificielle.
  • Le 12 mai à Paris, le Café IA #5 propose de débattre de la place de l’IA dans notre cercle intime, amical et de son impact sur la santé mentale.
  • Le 12 mai à Revigny-sur-Ornain, le Café IA du Pôle Coopératif questionne l’impact environnemental et énergétique du développement de l’IA, ainsi que les usages plus frugaux possibles.
  • Le 14 mai à Ceyzériat, le Café IA organisé avec OKTEO propose de comprendre les usages, les outils et les avantages de l’intelligence artificielle dans les pratiques professionnelles.

Vous organisez un Café IA grand public en France ou à l'étranger ?

Inscrivez vos sessions, ou découvrez les sessions proches de chez vous dans le recensement national et sur la cartographie interactive.

Inscrire mon Café IA

Vous organisez un Café IA à destination des entreprises, PME-TPE, inscrivez-les dans l’Agenda France Num. Les Cafés IA à destination de la communauté enseignante, des élèves et des parents d’élèves se retrouvent sur l’annuaire du Réseau Canopé. 

 

🎨Les Cafés animation à venir !

 

Vous souhaitez animer un Café IA ou partager votre expérience ? Participez aux prochains cafés animations en ligne, le jeudi de 13h30 à 15h pour découvrir des formats d’animation, des ressources pédagogiques sur l’IA et faire part de vos retours d’expérience. Un moment convivial pour s’inspirer et apprendre ensemble !

 

Le mois de mai s’annonce bien chargé. Nous vous donnons deux rendez-vous pour poursuivre les échanges autour de l’IA :

  • Mercredi 13 mai : découvrir le jeu Aïe Aïe IA, un format ludique pour animer un Café IA et ouvrir le dialogue autour des usages de l’intelligence artificielle.

  • Jeudi 28 mai : Augustin Remay abordera l’impact énergétique de l’IA générative, avec des 20 cartes et de nouvelles ressources pédagogiques à découvrir.
Je m'inscris
 
 

💥La ressource de la semaine

 
 

Un morpion de l’IA, pour comprendre comment l’IA apprend à gagner

 

Hexapawn est une sorte de jeu de morpion en papier, inventé en 1962 par un vulgarisateur scientifique américain. Son but : montrer comment une machine peut apprendre à gagner, en s’améliorant progressivement. Il va demander aux jeunes joueurs (dès 9 ans) beaucoup de patience pour réaliser son impressionnant matériel tout en papier et tout autant pour procéder aux innombrables parties qu’il faut pour que les règles ouvertes de l’IA éliminent les coups qui l’a font perdre. Un jeu peut-être un peu fastidieux, mais assurément instructif.

 

La vidéo explicative du fonctionnement du jeu et les instructions et le matériel à imprimer sont disponibles sur le site du Palais de la découverte.

 
 

👋 Avant de partir

 

Merci de nous avoir lus ! Si vous avez apprécié la lettre d’information de cette semaine, partagez-la ! Tout à chacun peut s’inscrire ici.

 

Comme d’habitude, n’hésitez pas à nous faire vos retours. Vous avez des questions, des remarques ou des suggestions ou vous souhaitez que nous abordions un sujet en particulier ? Nous sommes à votre écoute ! N’hésitez pas à répondre à ce mail ou à nous écrire à bonjour@cafeia.org. 

LinkedInInstagram
 

Se désinscrire.