Développeur au portable, IDE et assistant de programmation IA

Depuis deux ans, la course aux outils de programmation IA porte sur de meilleures complétions, des fenêtres de contexte géantes, des agents multi-fichiers plus audacieux et une intégration IDE plus fluide. Cursor, GitHub Copilot, Windsurf et Claude Code ont normalisé le passage « du chat au patch dans le dépôt ».

Mi-2026, beaucoup d'équipes constatent pourtant le même écart : une session impressionne, la collaboration sur plusieurs semaines trébuche. Les conventions de nommage fixées hier réapparaissent aujourd'hui dans un autre style ; le problème de signature CI résolu la semaine dernière revient dans la PR. Ce n'est pas forcément un modèle « moins intelligent », mais le passage d'assistant sans état à partenaire qui doit retenir décisions et conventions d'une session à l'autre — une front qui ne fait que s'ouvrir.

Les slides vantent 200K ou 1M tokens. Au terminal, la question est autre : Le lundi prochain, se souviendra-t-il encore pourquoi on a choisi ../pool-ci-mac-entreprise-2026-git-worktree-clone-par-job-multirepo-pr-nvme-cache-faq/pool-ci-mac-entreprise-2026-git-worktree-clone-par-job-multirepo-pr-nvme-cache-faq.html plutôt qu'un clone par job, et comment isoler les keychains ? Cet article sépare « visible cette fois » et « correct la prochaine fois », avec une pratique utilisable avant le prochain round produit.

1. Fenêtre de contexte XXL ≠ mémoire inter-sessions

Le marketing promet d'énormes context windows. En pratique : ce qui tient dans la fenêtre n'est pas réutilisé correctement au prochain cycle.

Dimension Fenêtre de contexte longue Mémoire gouvernée entre sessions
Portée Conversation / tâche actuelle Entre Composer, branches, idéalement projets
Sources Fichiers @ manuels, onglets ouverts Décisions passées, préférences, notes d'incident
Coût Tokens par requête, plus long = plus cher Écriture unique, faible coût à la récupération
Échec Session fermée, changement de modèle, troncature Faux souvenir, expiration, conflit, mauvaise fusion
Métaphore Très grand tableau blanc Carnet indexé + post-its mis à jour

La fenêtre répond à « est-ce visible maintenant ? » ; la mémoire inter-sessions à « le saura-t-on la prochaine fois — correctement ? » Sur une codebase, c'est impitoyable : index monorepo + fil PR remplissent la fenêtre ; même avec de la marge, injecter tout l'historique de chat n'est pas une solution d'ingénierie — le bruit noie le signal, d'anciennes consignes contradictoires déstabilisent le modèle.

Notre FAQ pool CI Mac entreprise et worktrees montre que le « pourquoi de cette config » vit souvent dans les runbooks. La programmation IA multiplie cela en des dizaines de micro-décisions par développeur et par jour.

Contre-exemple : Deux ou trois fichiers, règles entièrement dans le lint et la CI — empiler des tokens rapporte peu. Mettez l'oubliable dans des checks exécutables, pas dans une fenêtre plus longue.

Un autre piège : l'inflation de contexte par défaut — @ sur tout docs/, les ADR ou des exports Slack sans priorité. Le modèle « prend en compte » tout, mais les patches suivent souvent les dernières consignes et le diff courant. Sans couche inter-sessions, vous payez cher la même réunion ; avec couche, les ADR entrent dans l'index avec métadonnée « encore valide ? », pas en charge intégrale à chaque requête.

Sur Mac, projets Xcode, provisioning et état simulateur alourdissent le dépôt. Une grande fenêtre lit plus de fichiers, sans remplacer des faits comme « quel profil est dans le keychain de ce runner » — la même logique pool/isolation que dans nos articles CI entreprise.

2. Pourquoi le code est « avide de mémoire »

Pour des e-mails, oublier coûte une répétition du contexte. Pour du logiciel, ce sont des incidents mesurables :

  • Les décisions d'architecture vieillissent : « worktree plutôt que clone par job », « keychain par runner » — rarement dans le README, souvent dans un commentaire de review.
  • Les conventions sont implicites : gestion d'erreurs, arborescence de tests, format de commit, chemins interdits — éparpillés entre .cursor/rules, AGENTS.md et folklore oral.
  • Le debug est épisodique : « TestFlight a échoué à cause des droits de clé ASC » mérite une mémoire d'épisode, pas 200 lignes de log à chaque run.
  • Les frontières bougent : préférence perso, règle projet, conformité dans le même réservoir → fuite ou contamination croisée.
  • Les chaînes d'outils changent : Composer aujourd'hui, mode Agent ou passerelle distante demain — la mémoire liée à un seul éditeur sous-estime la migration.

Cela fait écho à notre FAQ codesign parallèle et isolation keychain : l'ingénierie plateforme veut du reproductible et auditable, pas « on l'a dit dans le chat ». Quand l'IA commit, « dit » doit devenir « dans le dépôt ou dans les checks ».

Les PM demandent : « L'IA peut lire tout Confluence ? » Mieux : « Quelles décisions influencent encore build et release dans 90 jours ? » Le premier remplit la fenêtre, le second va en L4/L5. Des demi-vies dans la stratégie — revue trimestrielle des politiques de montée de version, contournements hotfix en TTL 30 jours — battent la croissance brute des tokens.

3. Cinq niveaux : du produit à l'infrastructure

Les outils actuels simulent la mémoire via index, rules et état de session — sans modèle unifié et gouvernable. Cinq niveaux grossiers :

  • L5 Organisation : normes d'équipe, conformité, runbooks, postmortems
  • L4 Projet : ADR, frontières de modules, pièges CI, politique de montée de version
  • L3 Personne : style, alias shell, tics IA détestés
  • L2 Session : objectif, fichiers modifiés, conclusions intermédiaires (éphémère)
  • L1 Contexte immédiat : fichiers ouverts, curseur, git diff

Les forces sont en L1–L2 ; le marché se bat sur L3–L5. La prochaine vague : cinq pages de réglages disjointes ou un pipeline de mémoire versionnable.

Aligné avec OpenHuman et l'agent personnel à mémoire longue : la compétition glisse du « plus gros modèle de base » vers « comprendre stablement l'utilisateur et le projet » — en code IA, le front est le dépôt et la pipeline.

Pour les équipes Mac, L4–L5 se lient au matériel : quel runner tient les profils de signature, où tourne l'index d'embeddings — pas un problème de « un onglet de chat de plus ».

Dessinez les cinq niveaux en flux de données : L1 lecture seule, L2 jeté après la tâche, L3 exportable mais privé, L4 via PR, L5 avec approbation. Pour chaque interrupteur « Memory » : quel niveau, qui supprime, journal d'audit ? Sinon la spéculation L2 devient pollution L4 permanente.

4. Voies techniques : la mémoire n'est pas « plus de logs de chat »

4.1 RAG

Embeddings sur ADR, reviews, anciens fils ; retrieval par tâche. + scalable, sources citables. − une mauvaise hit est pire que rien — métadonnées (dépôt, branche, date, deprecated) obligatoires.

4.2 Magasins structurés

Faits du type « mot de passe match dans le coffre 1Password X, confiance 0,9 ». Bon pour les faits d'ingénierie et corrections manuelles ; autre logique de fusion que le texte libre.

4.3 Compaction

Résumé structuré en fin de tâche, injection à la session suivante. Rapide, mais perte de détail ; les mauvais résumés se renforcent — échantillonnage humain requis.

4.4 Le dépôt comme mémoire

AGENTS.md, lint, scripts doctor ; l'IA ne propose que des patches. L4 le moins cher et le plus reviewable — comme « étapes reproductibles dans le dépôt » pour la CI Mac.

4.5 Local vs cloud

Embeddings locaux sur Apple Silicon pour la confidentialité ; mémoire cloud pour sync appareils et équipe. En 2026 : « l'IA me connaît » vs « l'IA ne doit pas connaître l'inconnu » — souvent dans la même entreprise.

Pour les développeurs Mac, cela rejoint la mémoire unifiée pour l'inférence locale et le cluster privé Mac Mini M4 : index code et mémoire sur un nœud always-on plutôt que tout en SaaS.

4.6 Évaluation : quand la couche mémoire fonctionne-t-elle ?

Trois métriques : taux de répétition (combien de fois le même contexte par type d'issue), régression (erreurs CI/signature qui reviennent), latence de correction (de « mal mémorisé » à effacé). Mesurer seulement le succès par session surestime la fenêtre et sous-estime le coût hebdomadaire — fréquent dans les tableaux de bord, rare dans le ressenti d'équipe.

5. Trois batailles sur la carte

Bataille 1 : personnel vs équipe. Sans priorité, l'agent choisit au hasard entre règles contradictoires. Gagnants : scopes explicites (user/project/org) et chaîne d'origine visible.

Bataille 2 : confiance. La mémoire auto fait gagner du temps et cimente les hallucinations. Gagnants : écriture confirmée ou PR, négation, TTL, doctor memory.

Bataille 3 : sécurité. Les fuites de dépôt sont connues ; « client en prod la semaine prochaine » ou « correctif pas encore publié » peut venir d'une recherche cross-projet. Gagnants : isolation locataire, filtrage d'entités, audit d'export.

Ensemble, le code IA devient de l'ingénierie plateforme gouvernée — comme la CI Mac est passée du « ça tourne » aux pools et à l'isolation (voir FAQ codesign/keychain).

Les agents sur Mac distant étendent le blast radius aux configs de passerelle et montages — autre modèle de menace qu'un simple chat SaaS.

6. Stratégie réaliste : empiler la mémoire avant le standard

Pendant que les produits se battent, les équipes peuvent découpler tout de suite :

  • AGENTS.md / .cursor/rules à la racine : frontières, chemins interdits, checks obligatoires.
  • Leçons en make doctor ou étape CI, pas seulement dans le chat.
  • Faits dans la doc, préférences dans les user rules.
  • Modèle de passation en fin de tâche : objectif / fait / ouvert / contraintes / ne pas toucher → issue ou PR.
  • Raccourcir les rules comme le dead code.
  • Secrets, noms clients, CVE non publiées : jamais en mémoire cloud.
  • Version passerelle, montages et AGENTS.md dans le même Git — rollback sans perte de contexte.
Pratique : Avec passerelle OpenClaw et Mac distant, externalisez la mémoire dans le même dépôt que la passerelle et les montages — blue/green ou rollback ne doit pas emporter le contexte avec la machine.

7. Conclusion : pas plus éloquent, mais fiable sur des semaines

Une mémoire corrigeable entre sessions est le seuil entre efficacité démo et collaboration de production. Les longues fenêtres élèvent le plafond sans résoudre l'état cumulé dans le temps.

Modèles de base et intégration IDE se commoditisent. Difficile à copier : mémoire dans le dépôt, conformité dans la politique org, CI et inférence locale sur une infra de confiance.

Ne pariez pas tout sur un interrupteur Memory. Documents, rules, scripts et habitudes de dépôt auditables offrent une sortie indépendante du fournisseur. Quand L3–L5 seront stables, « tout réexpliquer » disparaîtra — l'écart ne viendra pas de +5 % de QI modèle, mais d'une couche mémoire digne de confiance.

Si vous planifiez un Mac always-on pour agents : d'abord dépôt et pipeline qui retiennent, ensuite une fenêtre plus large — sinon des semaines de travail ressemblent à l'onboarding d'un collègue qui change chaque jour.

La mémoire doit être versionnée. Si L4 vit dans AGENTS.md, PR, diff et rollback comme le code. Sinon vous échangez des répétitions de chat contre des « méga-commentaires » non relus — tout pourrit. En CI Mac entreprise : les habitudes auditables réduisent plus la friction hebdo que la taille du modèle — la couche mémoire du code IA converge vers la même discipline.