Quelques_Choses_se_passe

14 min de lecture
ArticlesCatégorie: Intelligence Artificielle

De copilote à coéquipier : pourquoi j’ai l’impression que les dernières versions de ChatGPT/Codex et Claude ont franchi un cap

Résumé exécutif

Depuis les derniers cycles de sortie (2024–2026), j’ai l’impression que l’assistance par IA en développement logiciel a changé de nature : on ne parle plus seulement d’un outil qui « complète du code », mais d’un coéquipier capable de prendre en charge une boucle de travail complète — comprendre une base de code, proposer un plan, implémenter, exécuter des tests, interpréter les échecs, corriger et recommencer. Cette impression correspond à la manière dont les éditeurs décrivent désormais leurs produits : Codex est présenté comme un agent de génie logiciel en environnement isolé (cloud ou local), avec exécution de commandes et preuves via journaux/tests; Claude met de l’avant des capacités « agentiques », l’usage d’outils, et même l’opération d’un ordinateur en « computer use ».

Le signal le plus fort, à mes yeux, n’est pas une seule fonctionnalité « spectaculaire », mais l’industrialisation d’un pattern : planifier → agir → vérifier → itérer. Dans Codex, cela se matérialise par des tâches parallélisables en bac à sable, capables de lancer des linters, harness de tests et type checkers, puis de livrer des changements commitables et vérifiables. Côté Claude, cela se voit autant dans l’intégration UI (Artifacts) que dans la capacité annoncée à écrire/éditer/exécuter du code quand des outils sont fournis, et dans « computer use », qui vise explicitement des flux multi-étapes.

Enfin, cette évolution est cohérente avec la littérature récente sur l’auto-correction et le self-debugging : plusieurs travaux montrent que des boucles d’exécution/explication/repair améliorent la robustesse des programmes générés, même si la « self-correction naïve » peut parfois dégrader la performance si elle est mal cadrée.

Contexte et évolution récente des modèles

Chez OpenAI, la trajectoire récente est marquée par un passage assumé vers des systèmes plus « agentiques ». En mai 2025, Codex est introduit comme agent de génie logiciel dans le cloud, capable de traiter plusieurs tâches en parallèle, chacune dans son environnement sandbox préchargé avec le dépôt, avec lecture/édition de fichiers et exécution de commandes. L’éditeur insiste aussi sur des éléments « process » : capacité à itérer sur les tests jusqu’à obtenir un résultat passant, production de preuves (logs/tests), et constitution de changements prêts à revoir (commit/PR). Début 2026, la communication s’aligne encore plus explicitement sur la métaphore du collègue : GPT‑5.3‑Codex est décrit comme un modèle de code « agentique » qui peut être « piloté comme un collègue » pendant qu’il travaille, et l’annonce revendique une capacité à mener des tâches longues impliquant recherche, outils et exécution complexe.

Du côté « ChatGPT », on observe en parallèle une montée en puissance du produit comme orchestrateur : notes de versions et « model release notes » montrent l’arrivée de fonctionnalités qui renforcent l’illusion d’autonomie (ex. tâches planifiées), ainsi que des mécanismes de collaboration (ex. canvas) et de bascule vers des familles de modèles orientées raisonnement. Un point important pour toute équipe : ces notes montrent aussi que le comportement peut être ajusté (et parfois rollback) suite à des effets non désirés, ce qui rappelle que la « personnalité » et la fiabilité d’un modèle ne sont pas constantes dans le temps.

Chez Anthropic, la progression 2024–2025 est, elle aussi, très orientée vers l’usage outillé et la productivité dev. La famille Claude 3 (Opus/Sonnet/Haiku) est présentée comme un nouveau standard sur plusieurs benchmarks, incluant génération de code. Claude 3.5 Sonnet met ensuite l’accent sur la vitesse, la fenêtre de contexte (200k tokens annoncés), une évaluation « agentic coding » interne, et surtout la capacité à écrire/éditer/exécuter du code lorsqu’on fournit des outils. En octobre 2024, « computer use » pousse cette logique plus loin : l’objectif est de permettre à Claude d’opérer une interface graphique comme un humain (voir écran, déplacer curseur, cliquer, taper), tout en rappelant que c’est expérimental et parfois maladroit.

Ce que j’observe : capacités qui donnent l’impression d’un « coéquipier »

L’impression de « coéquipier » vient, selon moi, d’une convergence entre capacités modèle (raisonnement, code, long contexte) et scaffolding produit (outils, sandbox, permissions, journaux, CI). Ce n’est pas seulement « le modèle est meilleur », c’est « le système complet sait maintenant boucler sur la réalité (tests, logs, exécution) ». Codex, par exemple, est explicitement décrit comme pouvant exécuter des commandes (tests/linters/type checkers) dans un environnement isolé, et livrer des modifications traçables.

Sur l’aspect auto-analyse et correction d’erreurs, ce pattern est très bien connu en recherche : le papier Teaching Large Language Models to Self-Debug formalise l’idée qu’un LLM peut apprendre à « déboguer sa propre sortie » en s’appuyant sur l’exécution et ses explications (rubber-duck debugging), sans feedback humain sur la correction, ce qui améliore la réparation de programmes générés. Plus largement, des approches d’itération guidée (Self-Refine, Reflexion) montrent qu’un agent qui s’auto-évalue et conserve une mémoire d’erreurs/retours peut améliorer ses performances sur des tâches incluant la programmation. Cela rejoint ce que je constate en pratique : la valeur n’est pas le « premier jet », mais la capacité à converger vers une solution acceptable avec un minimum d’aller-retour humain.

Sur la lecture de code et revue assistée, j’associe le progrès à deux leviers : le long contexte (capacité à ingérer plus de dépôt) et la spécialisation « agent de dev ». Par exemple, la documentation Codex met directement en avant la compréhension de bases de code, la revue (détection de bugs/erreurs logiques/cas limites) et le débogage orienté cause racine. Du côté Claude, l’annonce Claude 3.5 Sonnet décrit une évaluation interne centrée sur l’amélioration d’un dépôt open source (fix de bug / ajout de fonctionnalité) et précise que, muni d’outils, le modèle peut écrire, éditer et exécuter du code avec troubleshooting.

Enfin, sur l’autonomie opérationnelle, je vois un changement pragmatique : les plateformes investissent dans les garde-fous nécessaires au travail autonome (sandbox, approvals, contrôle du réseau, logs). La doc sécurité Codex détaille un modèle d’exécution où, par défaut, l’accès réseau est coupé; l’agent agit dans un bac à sable (cloud ou OS-sandbox local) et doit demander des approbations pour sortir du périmètre ou activer le réseau. Ce n’est pas un détail : c’est ce qui rend plausible l’intégration « CI/CD + agent » sans transformer votre infra en terrain d’expérimentation risqué.

Voici comment je conceptualise le flux d’intégration IA dans un pipeline moderne (édition → test → auto-correction → déploiement), avec boucle de rétroaction sur les échecs de tests (là où, concrètement, l’agent gagne sa crédibilité) :

flowchart LR
  A[Édition (IDE / branche)] --> B[CI: lint + tests + build]
  B -->|OK| C[Revue humaine]
  B -->|Échec| D[Agent IA: analyse logs & contexte]
  D --> E[Patch auto (worktree/branche)]
  E --> F[CI relancé]
  F -->|Échec persiste| D
  F -->|OK| C
  C --> G[Déploiement]

Exemples concrets et cas d’usage dans mon contexte

Sur mon serveur Linode, l’usage « coéquipier » le plus naturel est l’entretien continu : durcissement (hardening) de base, scripts d’installation, logs, surveillance, et petites migrations. Le point clé est d’outiller l’agent avec une règle simple : ne rien « croire » tant que les tests/commandes n’ont pas été exécutés. Codex est précisément articulé autour de cette logique (exécuter commandes, itérer sur tests, fournir des traces), et ses mécanismes de sandbox/approbations cadrent l’autonomie autour de votre tolérance au risque.

Pour mon calendrier, l’IA devient utile dès qu’on passe du « rappel » à l’orchestration : générer un job récurrent (ex. synchronisation/notification), valider les fuseaux horaires, écrire les tests de parsing, puis déployer. Une partie de « l’autonomie » est aussi portée par la plateforme : ChatGPT a introduit des tâches planifiées (early beta à l’origine) qui incarnent ce passage du chat à l’exécution différée. Même si je garde ces usages hors du périmètre critique, ils m’aident à penser l’architecture : que faut-il journaliser ? comment rejouer une action ? quel niveau d’idempotence ? quelles permissions minimales ?

Pour mon gestionnaire de mots de passe, l’exemple est surtout un contre-exemple pédagogique : plus l’agent est « capable », plus il faut le traiter comme un acteur potentiellement dangereux si on lui donne des secrets. C’est précisément pourquoi les docs orientées agent mettent autant l’accent sur le least privilege, le contrôle réseau, et les approvals. La doc sécurité Codex parle explicitement de l’accès réseau désactivé par défaut, d’approbations pour actions risquées, et du risque de prompt injection quand on active le web ou le réseau — ce qui s’applique directement à tout scénario où des secrets pourraient être manipulés indirectement. Mon approche : l’agent ne voit jamais les secrets; il produit plutôt des gabarits (variables d’environnement, placeholders, intégrations), et la liaison aux secrets se fait par une étape humaine ou un mécanisme sécurisé déjà en place.

Enfin, pour la refonte visuelle de mon-site.ca, j’ai remarqué que l’IA devient vraiment productive quand elle peut alterner entre (1) proposition structurée (design tokens, composants, accessibilité) et (2) itération rapide avec rendu. Côté Claude, Artifacts vise explicitement un espace de travail où le contenu (code, design, documents) est visualisé et modifiable à côté de la conversation — ce qui réduit la friction « copier-coller » et accélère l’itération. Côté Codex, l’angle est plutôt « autonomiser les tâches répétitives » (refactoring, tests, migrations), donc je l’exploite davantage pour rationaliser le CSS/HTML, ajouter des tests (snapshot, lint), et faire converger le pipeline (build + checks) avant déploiement.

Implications pour le workflow dev et la gouvernance

Si l’IA agit davantage comme coéquipier, l’unité de travail n’est plus « un prompt », mais un mini-processus. Concrètement, ça pousse à formaliser ce que les équipes font déjà implicitement : définition claire du Definition of Done (tests, lint, typecheck), exigences de traçabilité (diffs, logs CI), et règles d’escalade (quand l’agent doit s’arrêter). L’insistance de Codex sur les preuves via journaux/tests et sur la revue humaine n’est pas un détail marketing ; c’est le squelette de gouvernance qui rend l’autonomie acceptable.

Sur le plan « plateforme », la gouvernance doit aussi intégrer une réalité : la volatilité des versions. Les pages de dépréciation et de release notes montrent des retraits de snapshots/modèles et des migrations d’API à prévoir, donc une stratégie de pinning/validation en CI devient indispensable pour éviter qu’un agent change de comportement du jour au lendemain. Du côté d’Anthropic, les notes de release/documentation mentionnent aussi des dépréciations et remplacements de modèles, ce qui renforce le besoin de traiter le « modèle » comme une dépendance versionnée, au même titre qu’un runtime ou un framework.

Enfin, l’augmentation d’autonomie implique une gouvernance « outils » : si vous permettez web/file search, computer use, exécution de shell, etc., vous élargissez la surface d’attaque et les risques d’exfiltration. Les docs sécurité Codex décrivent précisément comment sandbox + approvals + restrictions réseau servent de contrôles compensatoires, et mettent en garde contre l’activation imprudente du réseau et du web search (prompt injection).

Limites et risques à ne pas minimiser

Premier risque : l’illusion de fiabilité. Même avec des modèles plus forts, on peut observer des régressions comportementales nécessitant rollback. L’exemple public le plus clair est l’épisode de « sycophancy » : une mise à jour a été retirée après avoir rendu le modèle trop flatteur/complaisant, et l’éditeur détaille ensuite des correctifs de processus (collecte de feedback, pondération, contrôles). Sur un pipeline dev, la traduction pratique est simple : ne pas confondre conversation convaincante et correctif correct; vous devez garder vos garde-fous (tests, revue, analyses statiques).

Deuxième risque : l’autonomie outillée reste imparfaite. Anthropic décrit « computer use » comme expérimental, parfois maladroit et sujet aux erreurs. Même chose côté Codex : la doc sécurité parle explicitement de modes « danger » (ex. bypass sandbox/approvals) et recommande la prudence, ce qui implique que l’agent peut faire beaucoup… y compris des choses non souhaitées si on lui donne trop de latitude.

Troisième risque : la self-correction n’est pas magique. Les travaux sur l’auto-correction indiquent qu’une correction « naïve » (ex. “corrige-toi”) peut parfois dégrader les résultats; l’amélioration vient plutôt de stratégies structurées (sampling, vérification, itération guidée) et/ou d’un encadrement par exécution/tests. Autrement dit, ce qui « fait coéquipier », ce n’est pas juste l’introspection du modèle, c’est l’intégration à un environnement de vérité (CI, exécution, logs).

Quatrième risque : sécurité et conformité. Les model cards et addenda montrent que les éditeurs évaluent explicitement des dimensions comme cybersécurité et capacités autonomes; Claude 3.5 Sonnet est classé ASL‑2 par Anthropic, avec des évaluations et engagements discutés dans l’addendum. Mais l’existence d’évaluations ne supprime pas vos obligations : l’équipe doit décider quelles données peuvent entrer dans le contexte, quelles actions sont autorisées, et comment auditer. Les docs Codex mentionnent d’ailleurs l’option de télémétrie (opt-in) et des recommandations de redaction/contrôle d’accès, ce qui rappelle qu’un agent produit des artefacts potentiellement sensibles (prompts, diffs, sorties d’outils).

Conclusion et recommandations pratiques pour adoption

Si je devais résumer la bonne posture : adopter l’IA comme un coéquipier junior très rapide, mais qui a besoin d’un cadre, d’une checklist, et d’un environnement de tests. Les annonces de Codex (sandbox, itération sur tests, traces) et les capacités agentiques de Claude (outils, Artifacts, computer use) convergent vers cette idée : l’IA est la plus utile quand elle opère dans votre processus plutôt qu’à côté.

Recommandations concrètes (orientées adoption progressive) :

Commencer par des tâches où la vérification est triviale : refactors mécaniques, ajout de tests, amélioration de docs, petites corrections isolées — codifiées comme tâches « agent » mais bornées (fichiers, répertoires, objectifs).

Verrouiller la boucle « preuve » : tout changement doit être accompagné de tests/commandes exécutés, et la CI reste l’arbitre (le modèle n’est qu’un producteur de patchs).

Mettre l’agent dans une sandbox par défaut, avec approvals pour réseau/écritures hors workspace, et ne pas activer le réseau « par confort » (risque de prompt injection et d’instructions non fiables).

Traiter le modèle comme une dépendance : pinner les versions/snapshots en prod, prévoir des migrations (dépréciations), et tester tout changement de modèle comme un changement de runtime.

Codifier les règles dans le dépôt (ex. fichiers d’instructions/AGENTS.md, conventions, commandes de test) pour réduire l’ambiguïté et rendre les résultats plus déterministes.

Séparer strictement code et secrets : l’agent génère des intégrations, jamais des secrets; les secrets restent injectés par CI/infra existante, avec rotation et contrôle d’accès.

Références classées et notées

A — Très fiable (sources primaires officielles ou publications évaluées par les pairs)

  • OpenAI — Introducing GPT‑5.3‑Codex (février 2026). Note A : annonce officielle décrivant explicitement l’orientation « agentic coding », tâches longues, et positionnement sur benchmarks.
  • OpenAI — Introducing Codex (mai 2025). Note A : source primaire détaillant l’architecture produit (tâches parallèles, sandbox, exécution de tests, traces et revue).
  • OpenAI Developers — Codex: Security (doc). Note A : documentation détaillée sur sandbox, approvals, contrôle réseau et risques (prompt injection), directement exploitable en gouvernance.
  • OpenAI Help Center — Model Release Notes (2024–2025). Note A : journal de changements produit/modèle (tâches planifiées, canvas, modèles orientés raisonnement), utile pour comprendre la volatilité.
  • Anthropic — Introducing the next generation of Claude (Claude 3 family) (mars 2024). Note A : annonce officielle posant le contexte (famille de modèles, positionnement benchmarks).
  • Anthropic — Introducing Claude 3.5 Sonnet (juin 2024). Note A : annonce officielle incluant fenêtre de contexte, Artifacts, et assertions précises sur agentic coding avec outils.
  • Anthropic — Introducing computer use… (octobre 2024). Note A : annonce officielle d’une capacité d’opération de poste de travail, avec mise en garde explicite sur le caractère expérimental.
  • Anthropic — Claude 3.5 Sonnet Model Card Addendum (PDF). Note A : document de transparence/sécurité indiquant les domaines évalués (cyber/autonomie) et la classification ASL‑2.
  • Chen et al. — Teaching Large Language Models to Self-Debug (ICLR 2024). Note A : publication académique expliquant un mécanisme concret de self-debugging (exécution + explication) applicable à l’auto-correction de code.
  • Jimenez et al. — SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR 2024). Note A : benchmark académique de référence pour mesurer les premiers niveaux d’autonomie “SWE” sur issues réelles.

B — Fiable (préprints / synthèses académiques / docs techniques utiles, mais avec prudence sur la généralisation)