Pourquoi votre ordinateur portable ne doit plus jamais être votre poste de travail : anatomie d'une flotte d'agents où le calcul est éphémère et jetable, tandis que l'état souverain est sanctuarisé dans le cloud.
1. LA FIN DU POSTE DE TRAVAIL PHYSIQUE
Pendant des décennies, le quotidien d'un développeur était rivé à sa machine locale : son MacBook, sa tour Linux ou son ThinkPad. On y installait des dizaines d'outils, on y stockait des clés SSH secrètes, et si la machine tombait en panne ou était volée, la reconstruction de l'environnement prenait trois semaines d'enfer administratif.
Dès lors que vous faites collaborer des agents d'intelligence artificielle autonomes (J.A.R.V.I.S., Jules, Eywa), ce modèle traditionnel devient un fardeau dangereux :
- L'agent ne vit pas dans votre ordinateur portable : Il s'exécute dans des conteneurs distants, sur Cloud Shell, sur Codespaces ou dans des workers serverless.
- La fracture d'état : Si vos configurations vivent sur votre disque dur local, vos agents cloud sont incapables d'y accéder sans créer des ponts réseau risqués.
Le 24 septembre, nous avons gravé l'un des principes les plus libérateurs de notre charte : la Règle #79.
Règle #79 (Gouvernance Crilo Automation) :
Le poste de travail physique est un terminal d'accès jetable. Rien d'important ne vit en local. L'architecte peut détruire sa machine physique à tout instant : l'intégralité du travail, de la mémoire et des clés réside dans GitHub, Google Cloud et le coffre Google Secret Manager (GSM).
ARCHITECTURE « POSTE JETABLE » (RÈGLE #79)
──────────────────────────────────────────
TERMINAUX JETABLES ÉTAT SOUVERAIN PERSISTANT
(Zéro donnée locale) (Sanctuarisé & Immuable)
┌────────────────────────┐ ┌────────────────────────┐
│ Google Cloud Shell │ ──▶ │ GitHub (Dépôts Flotte) │
├────────────────────────┤ \ ├────────────────────────┤
│ Chromebook Crostini │ ────▶ ───▶ │ Google Secret Manager │
├────────────────────────┤ / ├────────────────────────┤
│ Pixel / Smartphone │ ──▶ │ Cloud Storage (Cerveau)│
└────────────────────────┘ └────────────────────────┘2. CALCUL JETABLE vs CONTINUITÉ PERSISTANTE
Le secret d'un système résilient repose sur la distinction radicale entre deux concepts :
1. Le Calcul Jetable (Ephemeral Compute)
L'environnement où tourne le code (l'instance Cloud Shell, le worker Jules, la machine virtuelle temporaire) n'a aucune valeur sentimentale. Il démarre, exécute une tâche, et peut être détruit la seconde suivante sans aucun remords.
2. La Continuité Persistante (Persistent State)
Ce qui a de la valeur, c'est l'état : les commits Git, les journaux d'événements scellés, les identifiants d'invariants et les secrets d'authentification chiffrés. Cet état ne vit jamais sur un disque dur éphémère. Il réside dans des coffres cloud souverains.
Grâce à cette séparation, réinstaller un poste de travail neuf ne demande aucun clone manuel : une seule ligne de commande suffit :
curl -sSL https://get.crilocom.com/jarvis | bashEn 60 secondes, l'identité Google est confirmée, les secrets sont rapatriés en mémoire depuis le coffre GSM, et l'espace de travail est immédiatement opérationnel.
Travailler en mode 100 % cloud permet à l'architecte de passer instantanément de son bureau à son smartphone ou à un terminal d'emprunt lors d'un déplacement, tout en retrouvant exactement la même flotte d'agents au travail, sans aucune discontinuité.
3. LE RÉFLEXE DE SÉCURITÉ OBLIGATOIRE : « HOST HEALTH »
Lorsque vos environnements d'exécution sont distribués, le premier réflexe au démarrage d'une session est de savoir où l'on se trouve.
Dans notre flotte, chaque agent ou humain applique le réflexe sacré :
hostname · whoami · pwdCe diagnostic instantané empêche toute confusion catastrophique entre un environnement de test local et une machine de production.
4. LES TROIS COMMANDEMENTS DU TRAVAIL JETABLE
- Ne laissez aucun secret traîner sur votre disque : Vos clés d'API doivent être extraites à la volée depuis un coffre distant et disparaître dès que la session se ferme.
- Committez ou périssez : Si un morceau de code n'est pas poussé sur une branche distante avec son Issue GitHub associée, il est considéré comme inexistant.
- Pensez nomade dès la conception : Si votre application a besoin d'un chemin en dur spécifique à votre machine, elle est défaillante. La portabilité relative (
~/...) est la seule loi.