Airship : le visual editor Figma-like qui parle à Claude Code et Codex (open source)
Le workflow dev-design classique est cassé. Tout le monde le sait.
Designer maquette dans Figma → exporte en PNG/Zeplin → dev essaie de reproduire fidèlement en code → 3 allers-retours → résultat final jamais vraiment iso →设计师 frustre, dev frustré, PM frustré.
C’est exactement ce que 0xnyn/airship (cité fin août 2026 dans le Reel Instagram DclUDz7CMsl) essaie de régler : un visual editor Figma-like qui dialogue directement avec Claude Code, Codex et OpenCode. Pas de mockup séparé, pas d’export, pas d’aller-retour. Vous éditez le visuel, l’agent code la modification en temps réel.
On a testé sur 2 prototypes clients. Verdict.
Le concept : “Visual editor for your codebase”
Le pitch officiel :
“Airship puts an infinite design canvas in front of your dev server. Select an element, describe the change, and watch Claude Code, Codex or OpenCode update the source — without rebuilding your UI in a separate design tool.”
Concrètement, ça veut dire :
- Vous ouvrez Airship dans votre éditeur (VS Code, Cursor) ou dans un browser
- Airship affiche un canvas design Figma-like par-dessus votre serveur de dev local
- Vous sélectionnez un élément (un bouton, une card, un composant)
- Vous décrivez le changement en langage naturel (“turn this into a github icon”, “make this 20% bigger”, “change color to #6E32BA”)
- Claude Code / Codex / OpenCode lit la description, modifie le source, et le résultat se reflète en temps réel dans le canvas
Le tout sans rebuild manuel, pas de reload infini, pas de fragmentation entre l’outil de design et l’IDE.
Pourquoi c’est différent de v0, Bolt, Cursor Composer
Vous connaissez déjà :
- v0 (Vercel) : génère du code à partir d’un prompt, mais pas d’édition visuelle continue
- Bolt.new : même idée, plus généraliste
- Cursor Composer : édition via chat, pas via canvas visuel
Airship se distingue sur 3 axes :
1. Le canvas infini avant le dev server
Vous voyez votre UI comme dans Figma (pan, zoom, sélection, layers), mais c’est branché sur votre code qui tourne. Pas de mockup séparé.
2. L’agent agit en streaming, pas en batch
Vous voyez Claude Code lire, écrire, éditer en temps réel dans un panneau latéral. Ça donne un retour visuel immédiat : vous savez ce que l’agent fait, vous pouvez interrompre si nécessaire.
3. Multi-agents supportés
Claude Code, Codex CLI, OpenCode — pas de lock-in à un seul éditeur. Vous choisissez l’agent que vous préférez selon le contexte.
L’expérience concrète : ce qu’on a testé
Chez Beemm, on a branché Airship sur 2 prototypes clients :
Test 1 : refonte d’une landing page
Objectif : redesigner la hero section de la landing d’un client SaaS RH. Avant Airship, ça nous prenait ~2h : export Figma → ouvrir le repo → décrire les changements à Cursor → rebuild → screenshot → comparer → itérer.
Avec Airship : 20 minutes. Le flow :
- Sélection de la section dans le canvas
- Prompt : “Make the CTA button 30% bigger, add subtle shadow, change copy to ‘Démarrer gratuitement’, gradient background purple to pink”
- Claude Code lit les 4 fichiers concernés, propose les diffs en streaming
- On valide → les changements apparaissent dans le canvas en live
- On itère 2-3 fois pour fignoler
Gain mesuré : 6× plus rapide sur ce type de tâche.
Test 2 : ajustement mobile
Objectif : rendre une sidebar desktop utilisable sur mobile (collapse en burger menu).
Avant : 1h de dev manuel + 30 min de QA sur 3 breakpoints.
Avec Airship : 25 minutes, dont 5 minutes pour écrire le prompt correctement. Le reste, l’agent s’en est occupé. Bonus : Airship a proposé une animation de slide que je n’avais pas demandée mais qui était élégante.
Les limites (vécues en test)
Airship est jeune (août 2026) et ça se sent :
1. L’agent peut faire n’importe quoi
Vous décrivez “make this button more modern”, et l’agent peut changer la couleur, la typo, le padding, les ombres, le hover state — parfois trop. Faut apprendre à être précis dans les prompts (“change background to #6E32BA, keep everything else unchanged”).
2. Pas de sync bidirectionnel avec Git
Si vous modifiez le code dans un autre terminal (git pull, autre agent), Airship ne s’auto-sync pas. Faut refresh manuellement le canvas. C’est pas dramatique mais c’est friction.
3. Latence sur les gros composants
Sur un composant React complexe (200+ lignes), l’agent prend 5-10 secondes pour proposer le diff. Sur des composants simples, c’est quasi-instantané.
4. L’open source est tout neuf
La doc est minimale, la communauté commence à peine, il y a des bugs. Mais le repo est sur GitHub, vous pouvez forker.
Pourquoi c’est intéressant pour les agences et startups
Airship n’est pas pour tout le monde. Mais pour certains profils, c’est une vraie avancée :
Pour les designers qui codent un peu
Vous voyez votre UI dans Figma-like, vous demandez à l’agent de modifier, vous validez le résultat. Vous n’avez pas besoin d’être un dev senior pour itérer visuellement sur votre produit.
Pour les devs qui veulent prototyper vite
Vous skippez l’étape “exporter depuis Figma, importer dans le repo”. Tout reste dans le même flow. Vous gagnez 30-50% de temps sur les allers-retours design-dev.
Pour les équipes pluridisciplinaires
Designer + dev + PM peuvent regarder le même canvas en temps réel, décrire ce qu’ils veulent, voir l’agent modifier. C’est un outil de collaboration autant qu’un outil de dev.
Comment on l’intègre chez Beemm
Pour nos clients qui développent des produits digitaux (SaaS, apps mobiles, sites e-commerce), on installe Airship dans le cadre de notre offre SaaS quand :
- Le client a une équipe design/dev séparée (friction réelle)
- Le produit est en phase d’itération rapide (besoin de prototyper vite)
- Le client veut réduire ses cycles de validation (objectif ROI mesurable)
Pour les autres (pure tech, pas de designer, produit mature), on le mentionne comme option mais on ne le pousse pas.
Verdict honnête
Airship est un vrai bond en avant sur le workflow design-dev, mais c’est pas encore un produit mature. C’est à tester sur des prototypes, pas sur du code en production critique.
Si vous bossez sur des MVP, des landing pages, des prototypes internes, installez-le, ça vaut 20 minutes de votre temps. Si vous êtes sur du code legacy avec 50 devs qui push en permanence, attendez 6 mois que ça murisse.
Pour nous, c’est devenu un must-have dans notre stack agence pour les phases de design rapide. On l’a intégré à nos outils recommandés dans beemmvision.com.
Sources : GitHub 0xnyn/airship (open source MIT), Reel Instagram @how-to-web-dev DclUDz7CMsl, tests internes Beemm sur 2 prototypes clients août 2026.
