Coding agents : quand l'individuel freine l'équipe

Soyons directs : si tu utilises des coding agents dans ta boîte, tu gères probablement un joyeux bordel.

Chaque développeur a sa propre config MCP, ses prompts customs, ses scripts d'automatisation que personne d'autre ne peut ouvrir. Et impossible de savoir ce qui s'est vraiment passé quand l'agent a tourné. Ton "infrastructure équipe" ? C'est juste un amas de raccourcis personnels maintenus par l'espoir et la mémoire collective.

C'est exactement le problème qu'a rencontré Assembled. Leurs coding agents marchaient nickel pour chaque ingénieur individuellement. Mais le workflow autour ? Chaotique. Vraiment chaotique.

Le problème avec les coding agents personnels

Voici ce qui se passe en général :

• Le dev A a un setup Claude Code lié à son fork GitHub et Linear.
• Le dev B préfère Codex avec Sentry et ses propres notifications Slack.
• Le dev C a construit une machine de Rube Goldberg en scripts que lui seul comprend.

Un départ ? Besoin de reproduire ce que l'agent a fait ? D'auditer si le résultat correspond à ce qui a été commité ?

Tu es bloqué.

Le vrai problème n'est pas l'utilité des coding agents (ils sont utiles). C'est qu'on les traite comme des éditeurs de texte personnels au lieu de les intégrer dans l'infrastructure équipe. Et ça crée trois problèmes :

1. Silos de connaissance — Une seule personne sait comment l'agent est configuré.
2. Lacunes de reproductibilité — Impossible de rejouer ou auditer les actions de l'agent facilement.
3. Barrières à la collaboration — Ce qui marche pour un ingénieur n'aide pas le reste de l'équipe.

143.dev : transformer les coding agents en infrastructure partagée

Assembled a built une solution en interne, et ils viennent de l'open-sourcer. Le résultat : 143.dev — une plateforme qui convertit les coding agents en infrastructure accessible à toute l'équipe.

L'approche est maligne : au lieu de faire tourner les agents localement sur des machines individuelles, tu les exécutes dans des environnements standardisés avec des outils cohérents et de la visibilité.

En pratique, ça donne quoi :

Plusieurs agents, une plateforme unifiée. Le système fait tourner Codex, Claude Code, OpenCode et d'autres harnais d'agents dans des sandboxes gVisor. Tu peux mixer selon le coût, les capacités et le type de tâche. L'équipe d'Assembled utilise par exemple GLM 5.2 pour les automatisations courantes (moins cher, rapide) et Codex ou Claude Code pour le travail manuel plus complexe. Même infrastructure, agents différents selon les jobs.

Des intégrations outils prêtes à l'emploi. Le système se connecte à GitHub, Linear, Sentry, Slack, PagerDuty et plus. Générer des previews est simple. Tes agents ne tournent pas en vase clos — ils sont branchés sur ton workflow existant.

Sécurité sans friction. Les sandboxes gVisor offrent de l'isolation sans la galère de gérer des VMs complètes. Les agents font leur job, mais ils sont contenus.

Licence MIT et auto-hébergeable. Ce n'est pas un SaaS hébergé auquel tu dois confier ton code. Tu peux inspecter, faire tourner sur ta propre infrastructure, adapter à tes besoins. Assembled s'est inspiré du système Minions de Stripe et d'Inspect de Ramp, mais voulait quelque chose que la communauté puisse vraiment utiliser et modifier.

Pourquoi c'est important pour les startups et équipes en croissance

Voici le truc : les coding agents vont devenir de plus en plus courants. Et quand ton équipe grossit, l'approche "script personnel" ne tient plus.

Tu as besoin de :

• Pistes d'audit — Qu'est-ce que l'agent a vraiment changé ?
• Reproductibilité — Tu peux relancer la même tâche ?
• Partage de connaissance — N'importe qui dans l'équipe peut exploiter les workflows des agents ?
• Sécurité — Les agents n'accèdent qu'à ce qu'ils doivent ?

143.dev s'attaque à ces problèmes directement. Et le fait que ce soit open source signifie que tu ne mises pas ton infrastructure sur une startup qui pourrait ne plus exister dans deux ans.

Le tableau d'ensemble

On entre dans une phase où les outils de coding AI ne sont plus des gadgets — c'est de l'infrastructure. Et l'infrastructure se gère comme de l'infrastructure : avec de la visibilité, de la reproductibilité et un accès à toute l'équipe.

Les coding agents personnels, c'est un début. L'infrastructure d'agents gérée en équipe, c'est là que ça devient intéressant.

Si tu gères une startup ou une équipe engineering, ça vaut le coup de regarder 143.dev. Le code est sur GitHub, licence MIT. Pas de vendor lock-in, pas de coûts cachés — juste de l'infrastructure ouverte que tu peux adapter à la façon dont ton équipe bosse vraiment.

Parfois les meilleurs outils internes sont ceux qui méritent d'être partagés.