Google a lancé ses AI Overviews et son Mode IA en France en juillet 2026, une évolution des moteurs de recherche qui génèrent des réponses synthétiques en citant des sources. L’article explique que cette tendance, souvent désignée par des acronymes comme GEO, AEO ou SEO IA, relève en réalité d’une même logique : optimiser son contenu pour être visible dans ces réponses automatisées plutôt que dans les résultats traditionnels. L’auteur souligne que ces termes relèvent davantage d’un marketing d’agence que d’une réelle innovation technique.
L’article détaille les différences entre les moteurs comme Google AI Overviews, qui s’appuient sur leur propre index, et d’autres comme ChatGPT Search ou Perplexity, qui interrogent le web en temps réel. Un point clé est la nécessité d’être correctement indexé par ces plateformes, notamment Bing, dont les données alimentent partiellement des outils comme Copilot. L’auteur insiste sur l’importance de la crawlabilité (autorisation d’accès aux robots) et de la structuration des données pour maximiser ses chances d’être cité.
Enfin, l’auteur tempère les craintes en rappelant que Google lui-même affirme qu’il n’existe pas de recette magique pour ces nouveaux formats. Quatre ajustements techniques suffisent : garantir l’accès des robots au site, optimiser les données structurées (JSON-LD), produire un contenu clair et sourcé, et surveiller les performances via les outils d’analyse. L’objectif reste le même qu’en SEO classique : fournir une information de qualité, lisible par les humains comme par les machines.
Ce journal de Jérôme Flesch explore les défis techniques et les limites de l’auto-hébergement de grands modèles de langage (LLM) sur du matériel grand public, notamment face aux contraintes de CPU et RAM. L’auteur remet en cause les affirmations simplistes selon lesquelles des cartes graphiques modestes (comme une Nvidia GTX 1060 de 6 Go) suffiraient pour faire tourner des LLM efficacement, soulignant que ces démonstrations se limitent souvent à des tests basiques sans contexte réel. Il aborde aussi les modèles Mixture-of-Experts (MoE), censés optimiser les ressources, mais dont les gains dépendent fortement du matériel et des paramètres utilisés.
L’article détaille une méthodologie de tests comparatifs sur plusieurs GPU (Nvidia RTX 3060, AMD RX 9070 XT, Intel Arc Pro B60), analysant les performances en prédiction de tokens et en préremplissage selon la taille du contexte. Les résultats montrent des dégradations significatives des vitesses d’inférence dès que la mémoire vive est saturée, même avec des techniques comme le swap ou des optimisations logicielles. L’auteur souligne que les benchmarks superficiels, souvent partagés par des influenceurs, ignorent ces réalités matérielles, donnant une fausse impression de faisabilité.
En conclusion, Flesch conclut que l’auto-hébergement de LLM reste complexe et coûteux en ressources, surtout pour des usages intensifs. Il critique les solutions marketing qui minimisent ces contraintes, rappelant que les développeurs privilégient des GPU haut de gamme pour des raisons de performance et de stabilité. Le journal se veut un plaidoyer pour une approche pragmatique, loin des promesses exagérées circulant sur les réseaux.
L’article explique comment faire tourner un modèle de langage (LLM) en local sur un GPU AMD, en utilisant la pile logicielle ROCm, le serveur Ollama et l’agent OpenCode. L’auteur détaille les étapes pour configurer ROCm, éviter les pièges courants (comme l’utilisation involontaire de l’iGPU) et optimiser l’utilisation de la VRAM, notamment sur une carte RX 7900 XTX dotée de 24 Go de mémoire.
Le texte aborde aussi les concepts clés comme ROCm (l’alternative open source à CUDA pour AMD), Ollama (qui gère automatiquement le backend GPU) et OpenCode (un agent de codage IA en ligne de commande). Il souligne les défis liés à la gestion du contexte et du KV-cache, ainsi que l’importance de choisir un modèle adapté à la VRAM disponible.
Enfin, l’auteur partage son expérience pratique, en insistant sur la maturité actuelle de ROCm et sa compatibilité avec les dépôts Arch/CachyOS, tout en mettant en garde contre les erreurs fréquentes lors de la configuration. L’objectif est de permettre une utilisation autonome et locale d’un agent de codage IA, sans dépendre de solutions cloud ou propriétaires.
Ce billet de blog résume les actualités technologiques de juin et juillet 2026, avec un focus sur les conférences et la veille. L’auteur y partage ses coups de cœur, notamment des conférences comme Sunny Tech 2026, et aborde des sujets variés : Cloud Native (PostgreSQL sur Kubernetes, projets CNCF), intelligence artificielle locale (LLM légers, context engineering), souveraineté numérique (Proton Lumo, open source), programmation (Rust vs Go, optimisations) et DevOps (self-hosting, bonnes pratiques).
L’article met en avant des retours d’expérience concrets, comme l’utilisation d’un LLM de 35 milliards de paramètres sur une carte graphique ancienne ou la refonte d’un opérateur Kubernetes pour résoudre des problèmes de scalabilité. Il souligne aussi l’importance de la souveraineté numérique et des outils open source dans un paysage technologique en évolution.
Enfin, l’auteur évoque ses projets futurs et son rythme de publication, tout en partageant des ressources utiles pour les développeurs et les passionnés de tech.
L’article explique pourquoi les IA comme Claude génèrent du code standard, souvent éloigné des conventions spécifiques d’une équipe, et propose une solution via les rules. Sans instructions précises, l’IA se base sur des pratiques moyennes en ligne, ce qui peut entraîner des incohérences dans une base de code. Les rules permettent d’intégrer les bonnes pratiques internes sous forme d’instructions claires, comme des conventions de nommage ou des principes architecturaux, afin d’harmoniser le code produit.
Les rules sont des directives écrites au format DO/DON’T, intégrées à la session de l’IA pour guider ses choix. Elles couvrent des aspects variés, des unités de mesure aux bonnes pratiques comme le debounce pour optimiser les performances. Ces règles, une fois formalisées, réduisent les corrections répétitives en revues de code et facilitent la transmission des savoir-faire techniques au sein de l’équipe.
L’ajout excessif de contexte dans les instructions ou spécifications pour les agents de codage peut nuire à leur performance plutôt que de l’améliorer. Au-delà d’un certain seuil, ces agents deviennent confus, mélangent des détails de différents documents et génèrent des réponses erronées, notamment lorsque les spécifications deviennent trop détaillées ou obsolètes. Par exemple, des fichiers de spécifications trop techniques ou volumineux, initialement conçus pour décrire des comportements, finissent par inclure des détails d’implémentation qui induisent en erreur l’agent.
La question centrale soulevée est celle de la source de vérité dans le développement logiciel assisté par IA. Ni les tests, ni le code, ni les spécifications ne suffisent à eux seuls à garantir une compréhension fiable, car chacun reflète une réalité différente : les tests valident le comportement actuel, le code représente l’implémentation réelle (y compris ses défauts), et les spécifications, si elles ne sont pas maintenues, deviennent rapidement obsolètes. Sans une source de vérité claire et à jour, les équipes et les agents se retrouvent à deviner les intentions initiales, ce qui conduit à des incohérences.
Pour résoudre ce problème, une distinction utile consiste à séparer deux types de vérité : d’une part, la vérité exécutable (le code et les tests), qui reflète l’état actuel du logiciel, et d’autre part, la vérité intentionnelle (les objectifs, les contraintes architecturales et les attentes fonctionnelles), qui guide les évolutions futures. Cette séparation permet d’éviter que les agents ne s’appuient sur des informations contradictoires ou obsolètes, et clarifie le rôle de chaque élément dans le processus de développement.
L’article critique l’opposition systématique entre écologie et souveraineté numérique, en comparant cette tendance à l’erreur stratégique passée de la sortie du nucléaire en Europe. L’auteur souligne que refuser les datacenters en France, par exemple, ne réduit pas la demande globale en calcul, mais déplace simplement cette consommation vers des régions où l’énergie est plus carbonée et moins régulée, aggravant ainsi l’impact écologique.
Bien que la croissance du numérique pose des défis environnementaux majeurs, avec une empreinte carbone en hausse (passée de 2,5 % à 4,4 % en France), l’auteur nuance son propos en rappelant les bénéfices potentiels de l’IA et du numérique pour optimiser les énergies renouvelables, la médecine ou la logistique. Il met en garde contre une opposition simpliste qui ignorerait ces avantages, tout en reconnaissant les risques liés à l’industrie des datacenters, comme la dépendance aux énergies fossiles ou l’épuisement des ressources minières.
L’auteur plaide pour une approche équilibrée, combinant sobriété numérique et maîtrise des infrastructures critiques, afin d’éviter de reproduire les erreurs du passé et de préserver à la fois la transition écologique et la souveraineté technologique.
L’article aborde le piège de la vitesse dans le développement logiciel, où l’utilisation d’outils comme les IA et les agents accélère la production de code, mais risque de compromettre la qualité architecturale. L’auteur met en garde contre la confiance aveugle dans les solutions générées, qui peuvent mener à des bases de code fragiles et difficiles à maintenir.
Il souligne que la valeur d’un développeur ne réside plus dans sa capacité à coder rapidement, mais dans son jugement d’architecte, capable d’évaluer la pérennité des solutions. Pour éviter les erreurs, il propose des méthodes comme le "test des six mois" ou la rédaction préalable de documentation pour valider la solidité des choix techniques.
Enfin, l’auteur rappelle que la vitesse n’a de sens que si elle s’accompagne d’une réflexion approfondie, sous peine de créer des dettes techniques coûteuses à long terme.
Le GitLab MCP Server permet de connecter des assistants IA comme ChatGPT à des dépôts GitLab, qu'ils soient hébergés sur GitLab.com ou en auto-hébergement. Ce serveur, développé avec Symfony, expose des outils MCP pour interagir avec GitLab, offrant des fonctionnalités de lecture (liste de projets, exploration des fichiers, branches) et d'écriture (création de fichiers, commits atomiques jusqu'à 100 modifications). Les opérations destructives (suppression de fichiers ou projets) sont isolées et nécessitent des permissions spécifiques, renforçant la sécurité.
Pour sécuriser l'accès, le serveur utilise un système de permissions granulaires (lecture, écriture, destructif) et privilégie l'authentification OAuth 2.1 en production, avec vérification des jetons JWT et validation des scopes. Une configuration statique est disponible pour les tests locaux. Le transport est stateless via HTTP (Streamable HTTP ou Server-Sent Events), sans stockage de session, et les métadonnées OAuth sont publiquement accessibles pour faciliter l'intégration des clients.
L'installation requiert PHP 8.2+ et Symfony 7.4 LTS, avec une configuration Docker simplifiée. En production, l'OAuth est recommandé, tandis que le mode statique convient au développement. Le projet est conçu pour éviter les risques liés à la diffusion de tokens complets et pour maintenir un contexte à jour des dépôts.
L’article explore l’impact de l’IA générative sur le métier de développeur, soulignant que son adoption massive est désormais incontournable sur le marché du travail. L’auteur, Stéphane Philippart, explique que refuser d’utiliser ces outils peut devenir un frein professionnel, tant pour les recherches d’emploi que dans les entreprises, où la pression pour livrer plus vite est forte. Il compare cette évolution à d’autres révolutions technologiques passées, comme l’arrivée du Web ou des smartphones, où l’adaptation était nécessaire pour rester compétitif.
Plutôt que de parler de déclin, il insiste sur la nécessité de s’adapter, en transformant les pratiques sans pour autant renoncer à la passion ou à la créativité. L’IA ne supprime pas le métier, mais le fait évoluer, comme l’automatisation a pu le faire pour d’autres professions, comme les ébénistes. Certains peuvent choisir de rester sur des méthodes traditionnelles, mais cela devient un choix assumé plutôt qu’une obligation.
Enfin, l’auteur nuance son propos en reconnaissant que l’IA pourrait réduire l’espace dédié à la créativité pure, mais estime que le métier reste viable à condition de se réinventer. Il conclut que l’enjeu n’est pas de lutter contre cette tendance, mais de l’intégrer pour en tirer parti, tout en préservant l’essence du développement.
Cette page propose des méthodes pour désactiver ou limiter les fonctionnalités d'intelligence artificielle jugées intrusives dans divers outils technologiques. L'idée principale est de donner des instructions pratiques pour réduire la présence de l'IA dans des logiciels et appareils courants, comme Adobe Acrobat, Android/Gemini, Apple Intelligence ou les navigateurs Chrome, Edge et Firefox. Elle inclut aussi des astuces pour désactiver des assistants spécifiques comme Siri ou Copilot, ainsi que des extensions pour Firefox afin de bloquer les améliorations basées sur l'IA dans les résultats de recherche.
AAS Core est un contrôleur local axé sur les agents, conçu pour découvrir, valider et planifier des stacks de compétences (skills) via une interface en mémoire et un catalogue de plus de 1 987 compétences agentiques. Il permet aux agents comme Codex ou Claude d’inspecter un projet, de sélectionner des compétences spécifiques depuis un catalogue local, puis de valider ces choix via un outil en lecture seule (compose_stack) avant de générer un plan immuable (aas-stack.json) pour une exécution ultérieure.
Le projet inclut une CLI dédiée, un serveur MCP local (via stdio), des plugins et un Workbench pour faciliter la revue humaine des plans générés. Bien que la validation et la planification soient fonctionnelles, les phases d’application et de récupération restent expérimentales et non couvertes par le support officiel en préversion.
Le dépôt propose également des playbooks réutilisables (SKILL.md), une documentation structurée et des outils de vérification pour renforcer la sécurité et la cohérence du catalogue. La dernière version stable (v15.7.1) intègre des corrections de sécurité et des améliorations de stabilité.
L’article de GreenIT propose sept réflexes pour réduire l’impact environnemental de l’intelligence artificielle (IA), en insistant sur l’IA frugale comme solution efficace et économique. L’idée centrale est de questionner le besoin réel d’IA, notamment générative, souvent surutilisée alors que des alternatives plus simples (comme des tableaux de bord) suffisent. Par exemple, une entreprise a remplacé un LLM par un outil classique, économisant 150 kg de CO₂eq par mois, tandis qu’une autre a combiné IA symbolique et générative pour diviser par 100 ses émissions.
L’auteur recommande ensuite d’opter pour le modèle le plus petit possible, car sa taille influence directement sa consommation de ressources. Les modèles massifs, comme ChatGPT (2 000 milliards de paramètres), sont souvent disproportionnés pour des tâches courantes, où des modèles 200 fois plus légers (10 milliards de paramètres) peuvent suffire. Des études, comme celle de Luccioni et al., montrent que des modèles 60 fois plus petits restent performants, voire supérieurs pour certaines applications.
Enfin, l’article souligne que l’IA frugale permet non seulement de limiter l’empreinte écologique, mais aussi de réduire les coûts. En évitant les solutions surdimensionnées et en privilégiant des approches adaptées, les entreprises peuvent concilier performance et durabilité, tout en répondant à leurs besoins réels sans céder à la tendance du "toujours plus gros".
La « vibecoding fatigue » désigne une lassitude nouvelle touchant les développeurs informatiques, épuisés par l’utilisation intensive de l’IA générative. Cette fatigue, aussi appelée AI brain fry, résulte de la nécessité de valider en permanence le travail des outils d’IA, qui produisent rapidement mais génèrent aussi davantage d’erreurs. Un ingénieur cité dans l’article compare cette situation à « mettre sa bougie de productivité sur un lance-flammes », illustrant l’épuisement accru malgré une cadence de travail soutenue.
Les conséquences de cette tendance sont mesurables : une étude de 2026 révèle que 39 % d’erreurs graves supplémentaires sont générées par l’IA, tandis que 88 % des salariés les plus productifs grâce à ces outils déclarent souffrir de burn-out. Les développeurs, en tant qu’utilisateurs et concepteurs d’outils d’IA, sont en première ligne, mais d’autres métiers du langage, comme les journalistes ou les juristes, pourraient être touchés à leur tour.
Les modèles d’IA actuels, optimisés pour le code en raison de sa vérifiabilité, ont accéléré cette dynamique. Les entreprises du numérique, étudiées dans le cadre de recherches, observent une adaptation difficile à cette nouvelle forme de charge cognitive, soulignant un basculement dans l’organisation du travail.
REX DevLille 2026 : l’IA et le pragmatisme redéfinissent l’ingénierie logicielle
La conférence DevLille 2026 a mis en lumière l’impact croissant de l’IA dans le développement logiciel, au-delà des promesses marketing, ainsi que l’importance du pragmatisme face aux excès d’architectures complexes ou de réunions inefficaces. Les retours d’expérience soulignent une tendance à recentrer les pratiques sur l’efficacité et l’inclusivité, avec des outils concrets pour améliorer la collaboration.
Maxime Clément a abordé la problématique des Pull Requests (PR) interminables, souvent difficiles à relire en raison d’un manque de contexte et d’un ordre de fichiers peu intuitif. Sa solution propose de structurer les commits comme une narration, facilitant la compréhension des modifications. L’IA peut automatiser cette réorganisation, mais son usage doit être encadré pour éviter des commandes risquées, tout en gardant à l’esprit que les commits restent avant tout un outil pour les développeurs.
Par ailleurs, Vanessa Chodaton a évoqué les raisons du départ des femmes de la tech, un enjeu sociétal crucial pour l’industrie. Ces discussions reflètent une volonté de rendre le secteur plus durable et équitable, en intégrant des réflexions sur l’inclusion et les conditions de travail.
JoliCode relate la création d'une machine virtuelle PHP en Rust, rendue possible grâce à l'intelligence artificielle. L'idée principale est que les modèles de langage ont réduit la complexité de comprendre des bases de code inconnues et d'explorer des stratégies d'implémentation, rendant des projets ambitieux comme celui-ci plus accessibles. L'article souligne que l'IA ne produit pas de logiciel prêt pour la production, mais accélère significativement les phases de recherche et de prototypage.
Le premier prototype, bien que fonctionnel et réalisé en une journée, était extrêmement lent et adoptait une approche naïve. Il reproduisait une machine virtuelle à pile, contrairement à l'architecture registre de PHP, ce qui aurait pu poser des problèmes de compatibilité avec l'écosystème PHP existant. Ce prototype a cependant validé la faisabilité du projet, tout en montrant la nécessité d'une architecture plus réfléchie.
L'objectif n'était pas de copier fidèlement le moteur Zend de PHP, mais d'en tirer des enseignements pour concevoir une machine virtuelle alignée avec la philosophie de Rust. Cela implique d'adopter la gestion de la mémoire par ownership, d'éviter les états mutables globaux et de minimiser l'usage de code unsafe, afin de tirer pleinement parti des avantages de Rust plutôt que de simplement traduire du C en Rust.
L’auteur documente son approche d’une "usine logicielle" intégrant l’IA pour automatiser la production de code, tout en maintenant un contrôle strict sur la qualité logicielle. L’idée centrale est que l’IA excelle dans la génération de code, mais que la qualité dépend aussi de l’intention produit, de la gestion des risques (valeur, utilisabilité, faisabilité, viabilité) et de la fiabilité. L’outillage repose sur un context engineering précis, où des fichiers structurés (CLAUDE.md, règles thématiques, contraintes long terme) fournissent le contexte nécessaire aux agents, optimisé pour éviter la surcharge de tokens et les erreurs.
L’usine logicielle est organisée en couches : contexte (fichiers de référence), compétences (skills déterministes), outils (MCP, GitNexus, mémoire persistante), garde-fous (hooks, tests d’architecture) et processus de production (quality gates bloquantes, tests multi-étages). L’auteur souligne l’importance de standardiser les procédures pour limiter les risques, comme les dépendances non souhaitées dans un futur open source, vérifiées par des tests automatisés.
Enfin, l’auteur reconnaît des défis persistants, comme la standardisation des règles, l’évitement des rabbit holes (dérives coûteuses) et la mise à jour continue des compétences. Bien que le code soit quasi 100 % généré, la responsabilité humaine reste centrale pour garantir que le logiciel répond aux besoins métiers et techniques, au-delà de la simple production de code.
Nicolas Martignole, Principal Engineer chez Back Market, partage son expérience d’un an à accompagner plus de 300 ingénieurs dans l’adoption de l’IA générative. Il souligne une transformation radicale du métier, passant d’un codage manuel à la supervision d’agents automatisés, comparant ce changement à l’abandon du franc pour l’euro. L’adoption de l’IA s’est généralisée, avec seulement 6 à 8 % de réfractaires, souvent pour des raisons éthiques ou écologiques, tandis que les juniors, sans posture à défendre, sont les plus enthousiastes.
L’expérience professionnelle influence fortement les réticences : les profils seniors, attachés à leur expertise technique, résistent davantage que les juniors. Un conflit interne a illustré cette tension, aboutissant au départ d’un senior ayant tenté de limiter l’accès à l’IA pour des juniors motivés. À l’inverse, Martignole observe que les personnes neuroatypiques, comme un collègue Asperger, progressent rapidement grâce à l’IA, qui facilite leur communication.
Enfin, il évoque les défis organisationnels, comme la gestion des quotas d’utilisation pour éviter l’épuisement, illustrant les ajustements nécessaires face à cette révolution technologique. Son témoignage met en lumière à la fois les opportunités et les résistances liées à l’intégration de l’IA dans les pratiques professionnelles.
L’article met en garde contre le "bruit documentaire" généré par l’IA, soulignant que cette technologie facilite la production rapide de documentation technique, mais souvent au détriment de sa pertinence. Si l’IA peut décrire le quoi et le comment, elle néglige le pourquoi, essentiel pour comprendre les choix d’architecture et leurs contextes.
L’auteur souligne que la documentation automatisée risque de devenir pléthorique sans valeur ajoutée, car elle n’est ni relue ni appropriée par les équipes. Une documentation utile doit refléter une intention humaine et conserver l’historique des décisions, ce que l’IA ne peut pas générer seule.
Enfin, il conclut que l’IA peut assister la rédaction et la maintenance, mais la responsabilité de déterminer ce qui mérite d’être documenté et de transmettre la réflexion derrière les choix reste humaine.
Ce billet de Pascal Martin aborde la réalité du développement logiciel, où les développeurs passent souvent plus de temps à maintenir ou modifier du code existant qu’à en écrire de nouveau. L’auteur souligne que, même au sein d’une équipe, la connaissance approfondie d’un projet est rarement partagée par tous ses membres, chacun intervenant principalement sur des parties spécifiques. Il évoque aussi l’absence historique de pratiques comme les revues de code ou les tests automatisés, qui auraient pu faciliter cette maîtrise collective.
Martin illustre son propos par son expérience personnelle, où il a souvent dû intervenir sur des bases de code inconnues, que ce soit en SSII ou en tant qu’éditeur de logiciels. Il note que même les projets développés from scratch reposent souvent sur des composants partagés, et que l’ajout de nouveaux développeurs ne garantit pas une connaissance exhaustive du code.
Enfin, il remet en question l’idée reçue selon laquelle une équipe connaît parfaitement son propre projet, rappelant que les absences, les départs ou le simple passage du temps rendent cette maîtrise illusoire. Il interroge ainsi les pratiques de passation de connaissances et de documentation au sein des équipes.