L’article de Jérémy Decool souligne que l’utilisation de l’IA pour rédiger des documents persuasifs, comme des présentations ou des visions stratégiques, affaiblit leur impact. Bien que l’IA excelle pour des tâches techniques ou factuelles, elle produit des textes désincarnés, dépourvus de la personnalité et des convictions qui rendent un message convaincant. L’auteur insiste sur l’importance de l’authenticité et du style personnel pour transmettre une vision et mobiliser une équipe.

Scott H. Young aborde l’impact ambivalent de l’IA sur l’apprentissage, soulignant à la fois ses risques (dépendance, substitution du travail personnel) et ses opportunités (tutorat personnalisé, accès à des explications). Il s’appuie sur une analyse de Carl Hendrick, qui compare l’automatisation à l’IA, mettant en garde contre une surdépendance nuisible aux compétences fondamentales, comme le montrent les erreurs des pilotes face à l’autopilote.

L’auteur rejette les solutions simplistes, comme accepter aveuglément l’IA ou l’interdire, et propose une approche nuancée : l’IA doit être un outil complémentaire, comme une calculatrice ou Wikipédia, sans remplacer l’effort d’apprentissage. Il souligne que son utilité varie selon le niveau de maîtrise, bénéficiant davantage aux experts qu’aux débutants.

Enfin, Young s’interroge sur la quantité optimale d’IA à intégrer dans l’apprentissage, suggérant qu’un usage minimal pourrait aussi être contre-productif. Il défend l’idée que l’IA doit servir à renforcer les compétences, et non à les contourner, tout en reconnaissant la nécessité d’adapter les méthodes éducatives à cette nouvelle réalité.

L’auteur exprime son rejet de l’IA générative, principalement en raison de son impact écologique et éthique. Il souligne l’énorme consommation énergétique et hydrique des data centers, ainsi que l’extraction massive de terres rares pour les serveurs, aggravée par un renouvellement annuel des équipements. Il critique aussi l’usage massif de l’IA, même en phase d’inférence, qui multiplie ces problèmes malgré une consommation moindre par rapport à l’entraînement des modèles.

Il dénonce également les conditions de travail des personnes chargées d’étiqueter les données, souvent sous-payées dans des pays pauvres et exposées à des contenus traumatisants. L’auteur évoque aussi le pillage des données pour entraîner les IA, comparant le traitement judiciaire inégal entre les particuliers et les grandes entreprises, qui bénéficient d’une impunité relative malgré des pratiques similaires au piratage.

Enfin, il pointe du doigt l’aspect capitaliste de l’IA, avec des investissements colossaux et des valorisations boursières démesurées, reflétant une logique de profit au détriment des considérations sociales et environnementales.

L’article Why write code in 2026 défend l’idée que, malgré l’essor des agents IA et des outils automatisés, écrire du code reste essentiel pour les développeurs. L’auteur souligne que coder permet une compréhension directe de l’architecture logicielle, bien au-delà d’une simple lecture passive ou d’une supervision d’agents. Cette pratique favorise une meilleure attention aux détails, une réduction des erreurs et une amélioration de la qualité du code, évitant ainsi l’accumulation de "slop" (code bâclé) qui nuit aussi bien aux humains qu’aux agents.

L’auteur reconnaît que la plupart de son code est généré par IA, mais insiste sur le fait que l’écriture manuelle offre une expérience immersive et une maîtrise impossible à obtenir autrement. Il compare les agents IA à des stagiaires fraîchement embauchés, capables de suivre des instructions mais souvent limités par des descriptions imprécises ou des environnements mal structurés. Écrire du code permet de penser de manière algorithmique et de calibrer la précision nécessaire, contrairement à l’anglais, trop vague pour exprimer des computations complexes.

Enfin, l’article critique l’idée que les agents IA devraient être traités comme des compilateurs, ce qui justifierait la production de code médiocre. Au contraire, les développeurs doivent rester actifs dans le processus pour garantir la robustesse et la cohérence du logiciel. L’auteur cite l’exemple d’un choix d’architecture (local storage) qui, bien que fonctionnel, illustre comment une décision prise par un humain peut avoir des conséquences durables, soulignant l’importance d’une réflexion approfondie dans le développement.

Swival est un agent de codage open source conçu pour fonctionner avec divers modèles de langage, des plus performants aux modèles locaux plus modestes, en optimisant la gestion des contextes restreints et des ressources limitées. Il s’intègre facilement à des outils comme LM Studio, llama.cpp ou HuggingFace, et permet de choisir son modèle et son infrastructure. Ses fonctionnalités incluent une gestion intelligente du contexte, une mémoire persistante entre sessions et une sécurité renforcée avec chiffrement des secrets.

L’outil propose des mécanismes de revue et de benchmarking pour évaluer les performances des modèles, ainsi que des audits de sécurité autonomes pour détecter des vulnérabilités dans le code. Il supporte les protocoles A2A et ACP, facilitant son intégration avec des éditeurs comme Zed ou des agents externes. Son architecture modulaire permet d’étendre ses capacités via des skills ou des MCP servers, tout en restant léger et personnalisable.

Swival se distingue par sa fiabilité sur des modèles locaux, sa gestion optimisée du contexte et ses options de sécurité configurables, comme le chiffrement des secrets ou les restrictions d’accès au système de fichiers. Son installation rapide et sa compatibilité avec de nombreux fournisseurs en font une solution flexible pour automatiser des tâches de développement.

Ce billet analyse le trafic généré par les bots d’intelligence artificielle sur un blog PHP, en comparant les politiques définies dans le robots.txt avec la réalité des logs. L’auteur, après avoir constaté l’absence de données concrètes, a examiné 13,5 jours de logs (108 217 requêtes) pour évaluer l’efficacité de sa stratégie de blocage. Malgré une politique robots.txt restrictive et des outils comme Caddy et CrowdSec, les crawlers d’entraînement (comme Amazonbot) ont persisté, tandis que GPTBot (OpenAI) était absent.

L’étude révèle des limites méthodologiques, notamment l’impossibilité de tracer un tiers du trafic (lié à Docker) et l’absence de données vérifiables pour certains bots (comme ceux d’Anthropic). Les crawlers d’entraînement, bien que minoritaires (1,4 % des requêtes), ont consommé une bande passante non négligeable (13,4 Mo). L’auteur souligne l’importance de mesurer avant d’agir, une approche qu’il qualifie de "règlement affiché sans vérification".

Enfin, le billet conclut que les bots d’IA n’ont apporté aucun trafic référent (referral), remettant en cause leur utilité pour un site personnel. L’auteur envisage de durcir sa politique, tout en gardant une approche réversible, et invite à une réflexion sur l’équilibre entre ouverture et protection des données.

Le JSON-LD et schema.org permettent de structurer des données invisibles pour les humains mais exploitables par les agents IA et les moteurs de recherche. Ce format, basé sur un vocabulaire standardisé, décrit les relations entre entités (articles, personnes, organisations) via des identifiants uniques (@id) et des liens externes (sameAs), évitant les ambiguïtés. Bien que son utilité historique pour les rich results (comme les étoiles d'avis) ait diminué, il reste pertinent pour l'attribution des contenus (titres, auteurs) et l'alimentation du knowledge graph de Google, notamment via des entités comme Organization ou Person.

L'auteur souligne que le balisage ne sert plus à obtenir des avantages immédiats en termes de visibilité, mais devient un pari stratégique pour l'ère des agents IA. Les mécanismes comme les références croisées entre nœuds (@graph) ou les liens vers des sources externes (ex. Wikidata) renforcent la crédibilité des données, alignées sur les critères E-E-A-T (Expérience, Expertise, Autorité, Fiabilité). Cependant, aucune métrique fiable ne mesure encore l'impact direct de ce balisage sur le référencement par les IA.

Enfin, le billet précise que certaines pratiques (FAQ, HowTo) ne sont plus utiles, tandis que d'autres, comme les BreadcrumbList ou les descriptions d'auteurs (knowsAbout), conservent une valeur pour le SEO traditionnel. L'accent est mis sur la qualité des données plutôt que sur leur quantité, avec une approche pragmatique : documenter les choix sans promettre de résultats quantifiables.

L’article de Carson Gross sur htmx explore l’interaction entre le développement logiciel et l’IA à travers un exemple concret lié à hyperscript, un langage de script alternatif pour le web. L’auteur, ambivalent face à l’IA malgré ses avantages, illustre le problème de l’apprenti sorcier : bien que l’IA (ici, Claude) ait rapidement identifié la cause d’un bug dans hyperscript (une régression due à un refactoring malencontreux), elle s’est révélée moins efficace pour proposer des solutions robustes, poussant l’auteur à corriger manuellement le code.

Le bug concernait la syntaxe fetch ... as JSON, où le mot-clé as était interprété comme une conversion d’expression plutôt que comme un modificateur de la commande fetch, en raison d’un changement dans la grammaire. L’IA a aidé à diagnostiquer le problème en quelques minutes, mais ses propositions de correction étaient souvent des solutions temporaires ou mal adaptées, soulignant ses limites face à des cas complexes nécessitant une compréhension fine du contexte.

L’expérience met en lumière les forces et faiblesses de l’IA : un outil puissant pour l’analyse rapide, mais peu fiable pour des solutions créatives ou nuancées. L’auteur évite ainsi de tomber dans le piège de la dépendance excessive, privilégiant une approche équilibrée où l’IA complète, sans remplacer, le travail humain.

L’auteur, informaticien et ancien expert judiciaire, compare l’arrivée de l’IA générative à d’autres ruptures technologiques qu’il a connues, comme les calculatrices, les ordinateurs personnels ou Internet. Il souligne l’impact potentiellement « effroyable » de cette technologie sur la planète, l’emploi et l’informatique, tout en reconnaissant son propre manque d’intuition face aux innovations passées.

Ayant testé des outils d’IA dans un cadre professionnel, notamment pour des tests d’intrusion (pentests), il décrit une accélération soudaine de leur adoption, illustrée par l’engagement financier d’un alternant pour un abonnement coûteux. Son expérience en cybersécurité révèle aussi une augmentation des attaques informatiques, dans un contexte où les ressources et expertises se raréfient.

L’auteur, bien que sceptique au départ, admet que l’IA transforme profondément son domaine, tout en insistant sur la nécessité de l’encadrer pour éviter les risques, notamment les fuites de données. Son billet reflète une prise de conscience face à cette évolution rapide et ses implications.

L’ère des agents IA redéfinit les critères de réussite professionnelle, où la capacité à choisir quoi construire et à évaluer la qualité devient plus précieuse que la résolution de problèmes standardisés. L’auteur, ingénieur expérimenté chez Google, souligne que les compétences techniques automatisables (comme le vibe-coding) sont désormais moins déterminantes que le jugement, l’intuition et la sélection de problèmes complexes ou originaux. Les parcours traditionnels, axés sur les réponses prédéfinies (comme à l’école), perdent de leur pertinence face à des agents capables de traiter des tâches à réponse unique.

Pour se démarquer, il recommande de privilégier les ressources rares – réputation, relations et track record – plutôt que les gains immédiats, comme illustré par son engagement dans l’open source, peu lucratif sur le moment mais porteur d’opportunités futures. L’accent est mis sur l’importance de trouver des problèmes plutôt que de simplement les résoudre, une compétence devenue cruciale à l’ère des agents IA qui absorbent les solutions existantes. L’expérience terrain, même dans des tâches répétitives ou abstraites, reste indispensable pour forger un jugement affûté.

Enfin, l’auteur met en garde contre une dépendance totale aux agents : une pratique délibérée, ciblant des problèmes significatifs et réalisés sans assistance, est essentielle pour développer une expertise profonde. Sans cette discipline, le risque n’est pas tant une baisse de qualité du code, mais une érosion de la capacité à distinguer le bon du médiocre, réduisant ainsi la valeur des professionnels à de simples exécutants de prompts.

Headroom est une couche d'optimisation de contexte pour les applications utilisant des grands modèles de langage (LLM). Son objectif principal est de compresser les données avant qu'elles n'atteignent le modèle, réduisant ainsi le nombre de tokens tout en maintenant la précision des réponses. Par exemple, il peut compresser les sorties d'outils, les résultats de bases de données, les fichiers lus ou les réponses d'API, permettant des économies significatives en coûts et en temps de traitement.

Le projet propose plusieurs algorithmes de compression adaptés à différents types de contenu, comme le code source, les logs ou les images, avec des taux de réduction allant jusqu'à 95 % selon le cas. Headroom s'intègre facilement aux applications existantes, soit comme un proxy transparent, soit via des bibliothèques Python ou TypeScript, ou encore des intégrations avec des frameworks populaires comme LangChain ou Vercel AI SDK.

Les résultats concrets montrent une réduction moyenne de 87 % des tokens sans perte de précision, comme illustré par des cas d'usage tels que la recherche de code ou le débogage d'incidents. Le projet met en avant des fonctionnalités comme la compression réversible, la détection automatique du type de contenu et l'optimisation du cache pour améliorer les performances des LLM.

L’article explore la dualité de l’IA générative en 2026, entre avancées concrètes et illusions marketing, en s’inspirant de la métaphore du Magicien d’Oz. D’un côté, des réalisations tangibles comme AlphaFold, qui a révolutionné la biologie en prédisant la structure de millions de protéines, ou des outils comme GenCast en météorologie, démontrent l’utilité de ces technologies. De l’autre, certaines applications surfent sur le buzz sans réelle autonomie, comme des systèmes de commande automatisée où des humains interviennent massivement en coulisses.

L’auteur souligne que les progrès sont réels dans des domaines ciblés (biologie, médecine, développement logiciel), mais que leur efficacité dépend fortement du contexte. Par exemple, l’IA excelle sur des tâches répétitives et bien définies, comme la génération de code avec GitHub Copilot, mais son apport se réduit sur des projets complexes. Cette nuance est souvent occultée par les discours promotionnels.

Enfin, l’article met en lumière des cas de tromperie pure, où des entreprises ont levé des millions en prétendant automatiser des processus alors qu’ils reposaient sur une main-d’œuvre humaine. Ces exemples, comme l’application Nate ou les systèmes de Presto Automation, révèlent une économie de l’IA parfois plus proche du leurre que de l’innovation, surtout dans un contexte où les valorisations boursières et les attentes des utilisateurs sont sous pression.

L’auteur explique pourquoi l’utilisation des modèles de langage (LLMs) pour coder, ou "vibe coding", ne lui convient pas personnellement. Il évoque son manque d’enthousiasme face à cette tendance, sans pour autant nier les avantages potentiels des outils d’IA pour certains développeurs.

Il souligne deux raisons personnelles : son aversion pour les coûts récurrents des services d’IA, qu’il juge absurdes, et son expérience en tant que développeur expérimenté, qui lui permet de relativiser les promesses de productivité instantanée. Il compare cette hype à d’anciennes innovations en outils low-code ou no-code.

Enfin, il s’appuie sur les travaux de Fred Brooks, notamment The Mythical Man-Month et No Silver Bullet, pour rappeler que la complexité du monde réel ne peut être entièrement simplifiée par des outils, même avancés. Pour lui, le codage reste une question de compréhension des abstractions et de gestion de la complexité, plutôt que de productivité pure.

Les UX Days 2026 ont exploré l’impact de l’intelligence artificielle sur les métiers du design, de l’UX et du développement, avec un accent sur la nécessité de concevoir avec conscience. Lors de la keynote d’ouverture, Pablo Ruiz-Múzquiz, cofondateur de Penpot, a souligné que l’avenir du design UX passe par l’open source, un modèle basé sur la transparence, la collaboration mondiale et la souveraineté numérique. Il a aussi mis en lumière les défis posés par l’IA, comme la conception d’interfaces adaptées à la fois aux humains et aux agents automatisés, brouillant la frontière entre UX et AX.

Matthieu Froidure, expert en accessibilité numérique et malvoyant, a abordé le rôle complémentaire de l’IA dans l’amélioration de l’accessibilité, sans pour autant remplacer les démarches humaines essentielles. Il a rappelé que les outils logiciels, contrairement au matériel, évoluent rapidement grâce aux LLM, permettant des expériences plus personnalisées et une interaction fluide avec les agents IA.

Enfin, la journée a souligné l’importance des choix éthiques et techniques dans la conception d’outils, comme Penpot, qui mise sur les standards ouverts et une interface intuitive pour favoriser l’inclusion et l’innovation collective.

Cette page présente une sélection de 15 outils open-source permettant d’exécuter des modèles d’IA localement sur Mac ou PC en 2026, couvrant des cas d’usage variés comme le choix de modèles, la transcription vocale, la synthèse vocale, le traitement d’images ou encore les assistants agentiques. L’auteur souligne les avantages de l’IA locale : confidentialité des données, indépendance des abonnements cloud et fonctionnement hors ligne. Trois outils sont mis en avant pour évaluer la compatibilité matérielle avec les modèles, comme CanIRun.ai qui détecte automatiquement les configurations possibles via navigateur.

L’article détaille aussi des solutions spécifiques, comme llmfit pour une analyse en ligne de commande ou whichllm pour classer les modèles selon leurs performances réelles plutôt que leur taille. Une section est consacrée à Apple Intelligence en CLI, une alternative gratuite pour les utilisateurs de Mac. L’auteur renvoie vers d’autres ressources pour des alternatives non-IA aux services cloud.

Cet article explique le fonctionnement interne des grands modèles de langage (LLM) en se concentrant sur leur architecture basée sur les transformers. L’idée centrale est que ces modèles reposent sur des blocs de transformers répétés, dont les mécanismes clés (tokens, embeddings, attention, etc.) permettent de traiter le texte de manière efficace. Les différences entre modèles proviennent principalement des données d’entraînement, de leur taille et des ajustements post-formation.

L’auteur détaille le processus de conversion du texte en données exploitables par le modèle, notamment via la tokenisation, qui découpe les mots en sous-unités (souvent des sous-mots) pour équilibrer efficacité et généralisation. Les embeddings, matrices géantes associant à chaque token un vecteur de nombres, donnent un sens mathématique aux identifiants numériques. La positional encoding permet ensuite au modèle de comprendre l’ordre des tokens, tandis que les mécanismes d’attention et de multi-head attention facilitent les interactions entre eux.

Enfin, l’article aborde la prédiction du token suivant, cœur de la génération de texte, et distingue les éléments architecturaux communs (comme le residual stream ou la layer normalization) des variations propres à chaque modèle (vocabulaire, taille, données d’entraînement). L’objectif est de fournir une compréhension intuitive, sans entrer dans les détails mathématiques complexes.

L’article critique l’idée selon laquelle l’ère de l’IA rendrait la technique obsolète au profit d’une approche strictement "product-first". L’auteur souligne que, malgré les gains de productivité permis par l’IA, la qualité technique reste essentielle pour éviter des problèmes comme des performances médiocres, une architecture chaotique ou des solutions ingérables. Il met en garde contre l’usage abusif de l’argument "product-first" comme prétexte pour négliger la rigueur technique, même si des compromis sont parfois nécessaires pour livrer rapidement.

L’auteur, qui utilise massivement l’IA pour coder, rappelle que savoir quoi construire ne suffit pas : le comment compte toujours, surtout pour des projets complexes. Il cite Rich Hickey pour rappeler que la simplicité et la clarté technique restent des piliers, même avec des outils avancés. L’IA accélère le développement, mais ne dispense pas d’une réflexion sur l’architecture et la maintenabilité.

Wikidata est une base de données libre et collaborative, gérée par la Fondation Wikimedia, qui stocke des connaissances sous forme de données structurées et interconnectées, contrairement à Wikipédia qui utilise du texte non structuré. Chaque entité y est identifiée par un identifiant unique (Q pour les éléments, P pour les propriétés) et organisée en triplets RDF, formant un graphe de connaissances exploitable par les machines. En 2024, Wikidata comptait plus de 1,5 milliard de triplets sémantiques, interrogeables via un point d'accès SPARQL public.

Cette structure permet des requêtes précises, comme identifier tous les écrivains français nés à Nantes, offrant des résultats exploitables directement, là où une recherche classique ne renverrait que des pages à consulter. Wikidata s'inscrit dans la logique du Linked Open Data, visant à décrire le monde de manière explicite pour une compréhension optimale par les machines, à l'instar des microdonnées JSON-LD utilisées sur les pages web.

Les grands modèles de langage (LLM) apprécient particulièrement Wikidata pour sa fiabilité et sa qualité, car elle fournit une source de données structurées et vérifiables, réduisant ainsi les risques d'hallucinations lors des réponses aux requêtes. Contrairement à des sources moins fiables comme les forums, Wikidata est considérée comme une référence solide pour enrichir les connaissances des modèles d'intelligence artificielle.

Le DevLille 2026, anciennement Devfest Lille, s'est tenu à Lille au Grand Palais, comme chaque année. L'auteur partage son expérience en mettant en avant la keynote d'ouverture animée par Frédéric Leguédois, qui a critiqué avec humour les dérives de l'agilité dans les projets logiciels, notamment l'utilisation excessive de processus lourds et de roadmaps peu utiles aux utilisateurs finaux. Il a également évoqué les estimations fantaisistes de retour sur investissement (ROI) souvent utilisées dans les organisations.

Lors de cet événement, l'auteur a participé à un codelab sur Rust, un langage de programmation de bas niveau, animé par Youssef Nait Belkacem et Jean-Eudes Couignoux. Ce workshop a permis de découvrir les bases de Rust et de développer un microservice en Domain-Driven Design (DDD), tout en réalisant un programme inspiré de Super Mario. L'auteur souligne la robustesse de Rust, son compilateur aidant à réduire les erreurs, malgré une courbe d'apprentissage plus raide que Go.

Enfin, Florian Lemaire a présenté Coolify, une solution d'auto-hébergement permettant de gérer ses propres services pour moins de 10 € par mois, d'abord sur un Raspberry Pi puis dans le cloud. Cette conférence a mis en lumière une alternative économique et flexible pour l'hébergement de projets personnels ou professionnels.

Le blog d'Ippon explique comment gérer efficacement le cycle de vie des skills IA, ces modules qui étendent les capacités des agents conversationnels. L'idée centrale est de les traiter comme du code : conception, tests, évaluation et archivage sont essentiels pour éviter des dysfonctionnements silencieux, surtout lors des mises à jour des modèles. Les skills reposent sur un standard ouvert, le fichier SKILL.md, dont la description joue un rôle clé en tant que trigger pour l'agent, limitant ainsi la pollution du contexte.

Deux types de skills sont distingués : les capability uplift, qui ajoutent des compétences manquantes à l'agent (et vieillissent rapidement), et les encoded preference, qui organisent des processus existants (et restent stables). Leur gestion nécessite des evals pour détecter l'obsolescence ou vérifier la conformité aux workflows. Une mauvaise description peut rendre un skill inutilisable, car l'agent ne sélectionne que cette partie pour décider de son activation.

Enfin, le cycle de vie complet inclut design, tests, déploiement, observation et archivage. Négliger une étape entraîne une dégradation (skill rot), avec des fichiers obsolètes encombrant l'écosystème. La clé réside dans une approche structurée, partant de la description pour garantir une intégration efficace et durable.