Un développeur avisé ne démarre pas un nouveau projet en ouvrant une pull request géante. Ils passent par le brainstorming, les discussions entre collègues, le prototypage, les diagrammes, les propositions, les ADR, les MR/PR et GitOps – avec un Review Bot à chaque changement – et, lorsque l'échelle l'exige, l'architecture multi-agents de Workstation pour constituer une excellente équipe de développement qui exécute rapidement le travail de production.
1. Que signifie « sage » sur un nouveau projet
La sagesse, c'est un apprentissage précoce et peu coûteux, et des erreurs rares et coûteuses tardivement. La séquence ci-dessous est ordonnée de manière à ce que chaque étape réduise le rayon d'explosion de la suivante :
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. Remue-méninges
Avant de passer du temps avec les autres, passez 30 à 90 minutes seul :
- Résultat — qu'est-ce qui doit être vrai pour l'entreprise lorsque nous avons terminé ?
- Contraintes — temps, conformité, plateformes, compétences, budget.
- Non-objectifs - ce que la v1 n'inclura explicitement pas.
- Risques — données, sécurité, performances, verrouillage, charge opérationnelle.
- Indicateurs de réussite — choisissez-en deux (par exemple latence + adoption, ou coût + taux d'erreur).
Écrivez-le sous docs/ideas/. Les brainstormings non écrits s’évaporent.
3. Discussions avec des collègues
Invitez le plus petit cercle utile : un pair implémenteur, un propriétaire d'un système adjacent et un service de sécurité/SRE lorsque le risque le justifie.
- Durée (25 à 45 minutes). Terminez par des décisions ou des questions ouvertes.
- Options de force : A contre B contre reporter – pas d'accord vague.
- Désignez un scribe ; la note amorce la proposition.
- Considérez l’inconfort comme un risque pour l’ADR – pas de veto silencieux.
Les RFC asynchrones conviennent si quelqu'un ferme la boucle.
4. Prototypage
Spike lorsque l’incertitude est élevée. Des règles sages :
- Étiquetez-le comme une pointe ; définir un arrêt du calendrier (1 à 3 jours typiques).
- Gardez-le sur une branche jetable ou
spikes/— ne polissez pas. - Écrivez dix puces sur ce que vous avez appris (en particulier les échecs).
- Décidez : promouvoir, réécrire ou abandonner – ne jamais « devenir tranquillement un producteur ».
5. Diagrammes
Trois croquis suffisent généralement :
| Diagramme | Réponses |
|---|---|
| Contexte (C4 L1) | Qui parle à quoi ? Des limites de confiance ? |
| Séquence | Chemin heureux + un chemin d'échec |
| Déploiement | Où il fonctionne ; flux de configuration et de secrets |
Stockez Mermaid ou SVG à côté de la proposition. Mettre à jour lorsque les ADR changent.
6. Propositions
Gardez la RFC courte (1 à 3 pages) : problème, options (au moins deux), recommandation, impact (sécurité/coût/opérations), déploiement et restauration, questions ouvertes. Une fois approuvée, transformez la décision en ADR.
7. ADR — Enregistrements de décisions d'architecture
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
Conservez les ADR dans git (docs/adr/). Liez-les à partir des PR. Remplacer plutôt que réécrire l’histoire.
8. MR et PR — l'unité de livraison
M (Demande de fusion) et RP (Pull Request) sont la même idée : un ensemble de modifications révisables.
- Petit (préférez <400 lignes de différences significatives) ; une intention par changement.
- Description : pourquoi, comment tester, prendre des risques, revenir en arrière.
- Liens : ticket + ADR + schéma.
- Rédigez tôt pour obtenir des commentaires ; ne forcez jamais la fusion autour de résultats de CI rouges ou de robots de haute gravité sans exception écrite.
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. Review Bot – des commentaires automatiques qui protègent la production
Un Review Bot est un premier évaluateur automatisé. Cela ne remplace pas les humains ; il concentre ce qui est ennuyeux et dangereux afin que les développeurs consacrent du temps à la conception et aux risques liés aux produits.
9.1 Ce qu'elle doit commenter
- Sécurité : injection, lacunes d'authentification, fuite de secrets, valeurs par défaut non sécurisées
- Exactitude : chemins nuls, courses, migrations interrompues
- Tests : couverture manquante sur les nouvelles agences
- API/contrats : rupture des modifications sans changement de version
- Opérations : délais d'attente manquants, tentatives illimitées, écritures non idempotentes
9.2 Comment cela rationalise la vie des développeurs
- L'auteur ouvre PR → commentaires du bot en quelques minutes.
- L'auteur corrige ou répond avant de demander aux humains.
- L'humain lit le résumé du bot + se concentre sur l'architecture et le rayon d'explosion.
- Moins de lenteurs ; moins d'armes à pied échappées en production.
9.3 Politique qui maintient le bot utile
- Gravité : bloqueur / devrait-réparer / nit – les lentes ne doivent pas bloquer la fusion.
- Ignorer les chemins générés ; ajustez les faux positifs mensuellement.
- Exiger l'approbation humaine sur
auth/,infra/, IAM et chemins financiers. - Ne laissez jamais le bot être le seul réviseur sur les services critiques pour la production.
Câblez des robots SaaS (par exemple CodeRabbit), Cursor Bugbot ou une action personnalisée + LLM sur la différence PR. Couche de peluches → SAST → LLM pour la posture la plus solide.
10. Meilleures pratiques GitOps pour une qualité de production
L'état souhaité réside dans git. Un réconciliateur (Argo CD, Flux, etc.) fait correspondre le cluster. La promotion est une fusion ; la restauration est un retour.
- Séparez le code de l'application et la configuration d'environnement (ou effacez
envs/dev|staging|prodsuperpositions). - Pas de ponctuel
kubectl applyà pousser comme le chemin heureux - bris de verre uniquement, audité. - Livraison progressive : synchronisation automatique des environnements inférieurs ; synchronisation fermée pour la prod.
- Les images sont résumées sur des balises mutables dans la prod.
- Politique sous forme de code (OPA/Kyverno) pour les privilèges et les registres.
- Observez après la synchronisation ; pratiquez le retour.
La qualité du code ne se limite pas à des fonctions propres, c'est aussi comment le changement entre en production.
11. Architecture multi-agents des postes de travail – constituer d'excellentes équipes de développement
Un développeur avisé a encore besoin d’un effet de levier. L'architecture multi-agents de Workstation (packages de postes de travail Agentic AI et OpenClaw for Business lorsque vous avez besoin d'équipes d'agents incarnés ou spécialisés) vous permet créer automatiquement une équipe de développement autour d’un briefing commercial – et non d’un organigramme statique.
11.1 La boucle de composition
- Bref — résultat pour les parties prenantes, contraintes, SLA.
- Composer — mapper les rôles aux compétences (Planificateur, Constructeur, Réviseur, Opérations, Conformité).
- Amorçage — runtime de l'agent + outils MCP + mémoire + piste d'audit.
- Exécuter — les agents effectuent le travail, le mettent en œuvre par rapport à Spec/AC, mini-revoient chaque étape.
- Examen jusqu'au nettoyage — Review Bot + agents réviseurs + portes humaines.
- Bateau — GitOps fait la promotion de l'environnement qui compte.
11.2 Carte des rôles (humain + agent)
| Rôle | L'agent fait | L'humain possède toujours |
|---|---|---|
| Planificateur | Épopées, histoires, AC de Spec | Réductions de priorités et de périmètre |
| Constructeurs | Implémentation parallèle, tests | Jugement de domaine sur les bords durs |
| Réviseurs | Conformité aux spécifications, triage des Review Bot | Approbation de l'architecture et du produit |
| Opérations | Synchronisation GitOps, surveillance SLO, restauration du brouillon | Commande de mise en service et d'incident |
| Porte HITL | Augmenter les écritures/dépenses risquées | Approuver ou rejeter |
11.3 Pourquoi cela crée de grandes équipes
- Spécialisation — chaque agent a un emploi ; la qualité augmente lorsque les rôles ne se confondent pas.
- Débit sans chaos - des constructeurs parallèles derrière un seul robot de spécification et de révision.
- Mémoire partagée des décisions — L'historique ADR + Spec + PR devient la mémoire à long terme de l'équipe.
- Mêmes portes que les humains — CI, Review Bot, CODEOWNERS, GitOps — les agents ne contournent pas la discipline de production.
- Vitesse des affaires – des heures pour constituer une équipe compétente au lieu de semaines à embaucher pour chaque pointe.
11.4 Comment il se connecte au chemin sage
Réfléchissez et discutez encore avec les humains. Les prototypes et les diagrammes existent encore. L'équipage multi-agents accélère rédaction de propositions, échafaudage ADR, tranches de mise en œuvre, triage Review Bot et promotion GitOps – tandis que les humains gardent leur jugement sur les résultats et les risques. C'est le modèle Workstation : des postes de travail agents et des packages OpenClaw configurés pour vos flux de travail, pas une fenêtre de discussion prétendant être une équipe.
12. Portes de qualité de bout en bout
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. Liste de contrôle de démarrage
- Créer
docs/ideas/,docs/architecture/,docs/adr/ - Ajouter un modèle PR/MR + CODEOWNERS + protection de branche
- Activer les vérifications pré-commit + CI requises
- Installer le Bot d'examen ; régler les filtres de chemin et les gravités
- Écrivez ADR-0001 : « Nous utilisons GitOps pour le déploiement »
- Définir les règles de promotion de l'environnement et un jour de jeu de restauration
- En cas d'évolution de la livraison : équipe multi-agents de Workstation debout (Planificateur/Constructeurs/Réviseurs/Ops) avec des portes HITL
14. Anti-modèles
- PR géants « WIP, veuillez approuver »
- Architecture uniquement dans Slack – jamais dans ADR
- Prototype fusionné en tant que production sans tests
- Désactiver le Review Bot car il harcèle
- Agents avec accès en écriture et sans portail humain
- Correctif pour produire en dehors de GitOps sans plan de retour
15. Clôture
Un développeur avisé traite un nouveau projet comme une séquence d'artefacts d'apprentissage (notes, diagrammes, propositions, ADR) puis le livre via de petits MR/PR surveillés par un Review Bot et promus par GitOps. L'architecture multi-agents de Workstation étend cette sagesse à une équipe de développement complète : agents spécialisés, spécifications partagées, jugement humain là où cela compte et portes de niveau production sur chaque chemin de vie. C'est ainsi que la qualité du code reste optimisée pour la production tandis que l'entreprise évolue rapidement.
Publié par Poste de travail.
