Ce tutoriel explique comment configurer Codex, l'agent IA d'OpenAI, pour l'utiliser avec un modèle de langage local (LLM) hébergé via llama.cpp. L'idée principale est d'éviter les abonnements payants des plateformes cloud en auto-hébergeant le LLM, tout en conservant les fonctionnalités de Codex. L'auteur insiste sur l'importance d'installer Codex sur une machine dédiée pour limiter les risques liés à son accès au système.
L'installation de Codex se fait via un téléchargement manuel depuis GitHub, suivi de son déplacement dans /usr/local/bin. L'outil bubblewrap est requis pour sécuriser l'exécution de Codex en mode bac à sable. La configuration repose sur un fichier config.toml où l'utilisateur définit le fournisseur de modèle (llamacpp), un nom personnalisé et l'URL locale de l'API de llama.cpp.
L’article souligne que l’IA facilite la génération de code, mais que la véritable difficulté réside dans la production de code de qualité, maintenable et évolutif. L’auteur, développeur expérimenté, rappelle que les problèmes actuels (logique dispersée, tests inefficaces, architectures mal conçues) existaient déjà avant l’IA, simplement amplifiés par son usage massif. Il insiste sur l’importance des bonnes pratiques d’ingénierie logicielle, comme l’abstraction, le découplage et la responsabilité métier, plutôt que sur l’outil utilisé.
L’article de Romain Lanz explore une méthode pour utiliser efficacement l’IA dans le développement logiciel sans déléguer la réflexion stratégique. Il souligne que, contrairement à une idée reçue, déléguer l’écriture du code à l’IA ne signifie pas renoncer à la maîtrise du processus, à condition d’adopter une approche structurée.
L’auteur détaille trois concepts clés : le modèle (le LLM utilisé), le contexte (les informations fournies pour guider la réponse) et le harness (l’environnement technique qui encadre l’IA). Il insiste sur l’importance de limiter le contexte, car un excès d’informations dégrade la qualité des réponses, et sur le rôle du harness, qui agit comme un intermédiaire entre le modèle et les outils concrets (lecture/écriture de fichiers, exécution de commandes).
Enfin, Lanz rappelle que l’IA reste un outil prédictif, incapable d’agir sans ces extensions techniques. Sa méthode vise à optimiser l’interaction avec ces outils pour en tirer le meilleur parti tout en conservant le contrôle sur les décisions techniques.
L’auteur explique avoir réduit le nombre d’agents IA qu’il utilise simultanément après avoir constaté que cette pratique créait une surcharge décisionnelle. Malgré une méthode de travail structurée (spécifications, tests d’acceptation), il a progressivement lancé plusieurs agents en parallèle, se retrouvant submergé par leurs questions et incapable de prioriser efficacement.
Il illustre ce problème avec la théorie des contraintes, soulignant que multiplier les tâches en amont d’un goulot d’étranglement (ici, sa capacité à arbitrer) ne fait qu’accumuler du stock invisible (branches ouvertes, PR en attente) sans améliorer la productivité. La fatigue décisionnelle qui en résulte affecte la qualité du travail, notamment la relecture de code généré par IA.
L’auteur conclut que cette dérive, bien que non imposée, révèle un défaut de gestion des priorités, aggravé par l’illusion de productivité offerte par les agents. Il compare cette situation à l’effet contre-productif d’ajouter des développeurs à un projet déjà en retard.
Cette page propose neuf méthodes pour optimiser l’apprentissage grâce à l’IA, en s’appuyant sur des principes pédagogiques éprouvés comme la récupération active, l’espacement et la pratique exigeante. L’idée centrale est d’utiliser l’IA comme un coach plutôt que comme une simple machine à réponses, en évitant de déléguer entièrement le travail cognitif à l’outil. Par exemple, transformer l’IA en tuteur socratique, qui pose des questions et guide l’utilisateur vers la compréhension plutôt que de fournir des solutions toutes faites, maximise la rétention des connaissances.
L’article insiste sur une règle fondamentale : l’IA doit assister l’effort d’apprentissage sans le remplacer, car c’est l’effort personnel qui renforce la mémoire. Les techniques proposées, comme la création de flashcards automatisées suivies de révisions espacées, illustrent cette approche en combinant gain de temps et efficacité pédagogique. L’accent est mis sur l’interaction active avec le contenu, plutôt que sur la consommation passive d’informations.
Enfin, le texte met en garde contre les limites de l’IA, notamment ses erreurs potentielles, et recommande de croiser ses réponses avec d’autres sources pour éviter les biais. Destiné aux apprenants de tous niveaux, l’article encourage à appliquer ces méthodes immédiatement sur un sujet précis, en adaptant les prompts fournis pour une utilisation concrète.
L’auteur critique l’usage des chatbots, qu’il compare à une forme d’onanisme intellectuel ou de Guitar Hero créatif : amusant mais stérile, car il ne développe aucune compétence réelle. Il souligne que les utilisateurs, même en ayant la réponse sous les yeux, échouent à la restituer, illustrant l’absence d’apprentissage. L’analogie avec un plaisir solitaire et peu partageable renforce son rejet de cette pratique, qu’il juge à la fois inefficace et dénuée de valeur ajoutée.
Ploum admet avoir lui-même cédé à la tentation, en testant un chatbot pour générer des images, mais souligne l’absurdité de l’exercice : l’outil produit des résultats superficiels, comme une musculature exagérée imposée à un personnage, révélant ses biais. Il insiste sur le paradoxe où l’IA, présentée comme un gain de temps, exige en réalité un investissement disproportionné pour un résultat médiocre, à l’image d’un jardinier trop coûteux pour une petite pelouse.
Enfin, il généralise cette critique aux dynamiques managériales ou parentales, où déléguer une tâche simple à un "expert" (humain ou machine) s’avère contre-productif. Son ton mêle ironie et sérieux, dénonçant une mode technologique qui sacrifie l’effort personnel au profit d’une illusion de facilité, sans réel bénéfice durable.
L’article explique comment moderniser un script de sauvegarde obsolète en utilisant Codex via l’extension Remote SSH de VS Code, plutôt que de réécrire aveuglément le code. L’auteur, confronté à des changements d’infrastructure (migration Debian, conteneurs Docker disparus), a préféré auditer le script existant en temps réel sur le serveur, en s’appuyant sur l’IA pour vérifier la validité des chemins, des commandes et des ressources (conteneurs, volumes, espace disque). Cette approche interactive permet de confronter les hypothèses du code à la réalité du serveur, évitant ainsi des erreurs liées à des hypothèses erronées.
L’outil Remote SSH de VS Code joue un rôle clé en transformant le serveur distant en espace de travail direct, où Codex peut analyser les fichiers et exécuter des commandes dans le contexte réel. L’auteur souligne l’importance de ne pas laisser l’IA agir sans contrôle, notamment en matière de privilèges : Codex propose des commandes en lecture seule et demande explicitement l’autorisation avant toute opération sensible, garantissant ainsi une supervision humaine constante.
Le processus a révélé des incohérences majeures dans le script, comme des chemins de sauvegarde inexistants ou des conteneurs Docker disparus, prouvant l’utilité de cette méthode. En combinant audit interactif et vérification immédiate, l’auteur évite une refonte hasardeuse et s’assure que la nouvelle version du script correspond à l’état actuel du serveur.
L’article de Maxence Maireaux analyse le retour du mythe du 10x engineer avec l’essor de l’IA, illustré par une thèse récente selon laquelle l’IA polariserait le métier de développeur. Les ingénieurs les plus compétents, capables de superviser et valider le travail des agents IA, deviendraient indispensables, tandis que les profils moyens seraient marginalisés. Les données, comme celles du rapport DORA 2024 ou des études METR, montrent cependant que l’IA peut aussi réduire la stabilité des livraisons et creuser l’écart entre productivité perçue et réelle, comme en témoignent des cas concrets de code généré sans vérification approfondie.
L’auteur reconnaît la pertinence du diagnostic sur les risques de la confiance aveugle dans l’IA, qui accélère l’accumulation de dette technique et la perte de connaissance des systèmes. Cependant, il critique la conclusion économique qui en découle, comparant ce raisonnement au mythe du 10x engineer, popularisé par une étude contestable des années 1960 et aujourd’hui relancé par l’IA. Ce mythe, qui glorifie les "stars" individuelles, ignore les leçons des recherches en psychologie organisationnelle, comme celles de Google, qui soulignent l’importance de la sécurité psychologique et du travail d’équipe plutôt que du talent isolé.
En conclusion, l’article met en garde contre la résurgence de cette croyance simpliste, rappelant que l’efficacité collective repose davantage sur des dynamiques collaboratives que sur des individus exceptionnels. L’IA, loin de justifier une segmentation extrême du métier, devrait plutôt inciter à repenser les méthodes de travail pour éviter les pièges de la productivité illusoire et de la dépendance technologique.
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é.