TPC
    TPC
    TechProductDesign

    Everyone Can Build @ Alan : Quand les PM et designers pushent en prod

    Tim (Engineering Lead) et Laure (Product Designer) expliquent comment Alan a onboardé 35 designers et 25 PM pour contribuer directement à la codebase. Cursor, Figma MCP, agents AI : les outils, les règles, les résultats concrets et les limites.

    10 min de lecture

    Tim (Engineering Lead) et Laure (Product Designer) expliquent comment Alan a onboardé 35 designers et 25 PM pour contribuer directement à la codebase. Cursor, Figma MCP, agents AI : les outils, les règles, les résultats concrets et les limites.

    1. Dépendance aux ingénieurs

    Des bugs et des maquettes qui restent dans les tiroirs

    Laure (Product Designer, Alan) pose le contexte. Des bugs visuels traînent dans le backlog depuis 2-3 sprints. Des mock-ups pour remplacer de vieux écrans avec la marque de 2017 restent dans les tiroirs. La vélocité produit dépend de l'appétit ingénieur. Les prototypes pour avancer dans les réflexions ne fonctionnent qu'avec des designers qui savent déjà coder.

    La dépendance freine la vélocité

    Roles séparés : le PM rédige les specs, le designer fait les mock-ups, l'ingénieur implémente. Perte d'information à chaque étape. Allers-retours sur des tweaks de padding ou des couleurs mal implémentées.

    Opportunites manquees

    Un designer a plus de motivation à régler un problème visuel. Il le voit immédiatement. Mais il dépend d'un ingénieur qui ne le voit pas forcément. Alan a tente de faire venir les ingénieurs sur Figma. Résultats variables.

    2. Everyone Can Build

    Tout le monde devient builder

    Le code devient l'interface partagée. On arrête de faire venir les ingénieurs sur Figma. Les designers et les non-ingénieurs éditent directement la codebase.

    Historique du projet

    Été 2023 : designers, ingénieurs, PM testent des produits (Lovable, Figma Mech, etc.). Découverte de Cursor et du Figma MCP : game changer. Création d'un crew avec mission : utiliser l'AI pour accélérer sur ce qu'on imagine, construit et améliore dans le produit.

    Q4 2024 : onboarding graduel

    Onboarding de tous les designers. Rework du setup. Éducation. Explorations.

    3. Les règles du jeu

    1. Focus front-end uniquement

    Use case principal des designers. Moins risque, plus facile à tester. Évite la complexité back-end et data model.

    2. Meme pipeline que les ingénieurs

    Pull requests obligatoires. Checks automatiques (tests, formatting, qualité) via CI. Feature flags pour enable graduellement en production.

    3. Systeme de budding

    Chaque non-ingénieur associé à un engineering buddy. L'ingénieur accompagne sur la compréhension de la codebase, la complexité, la review. L'ingénieur est responsable du merge en prod (safety net).

    4. Code industriel, pas du vibe coding

    Pas de prototypes jetables. Code avec la même qualité qu'un ingénieur. Process complet : PR, CI, Review, Merge, Deploy, follow-up en prod.

    4. Cursor, Figma MCP, templates PR

    Environnement de dev reproductible et isolé

    Meme environnement que les ingénieurs. Setup en une commande (meme pour les ingénieurs). Décomplexification d'un environnement technique complexe.

    Cursor : editeur de code avec AI

    Chat avec la codebase. Edition via conversation (comme avec un stagiaire en engineering). Integre le Figma MCP pour mapper design vers code.

    Figma MCP (Model Context Protocol)

    Connexion Figma vers la codebase. Génère du code a partir d'un lien Figma. Utilise Code Connect : mappe les composants Figma aux composants React du design system. Le MCP de Figma génère automatiquement le code qui respecte le design system.

    Template de PR dédié aux non-ingénieurs

    Guidance spécifique : checklist de ce qui a été teste. Mention de l'engineering buddy. Seconde checklist pour l'ingénieur qui review.

    Tooling pour tester facilement

    Déploiement de toutes les apps front-end sur chaque PR. URL dédiée avec les changements de la PR. Test facile pour le non-ingénieur, l'ingénieur reviewer, ou n'importe qui.

    5. Fix de marge avec Cursor

    Le bug

    Laure (Product Designer) veut corriger un bug visuel sur l'app Alan. Marges incorrectes sur un onglet (16px attendus, plus de 16px en réalité).

    Le process

    Screenshot du bug. Colle dans Cursor en mode chat. Prompt en francais : les marges sur l'onglet shop ne sont pas correctes, ça devrait être 16 pixels. Cursor analyse la requete, cherche où vit cet écran dans la codebase. Propose des changements (calcul de taille d'image, padding horizontal). Laure verifie visuellement.

    Iteration

    Si ça ne fonctionne pas : reprompt avec un nouveau screenshot. L'AI est probabilistique, ça ne marche pas toujours du premier coup. Laure doit iterer.

    Création de la PR

    Cursor peut automatiquement creer la branche, commiter, pusher et ouvrir la PR via prompt. Outils utilises : design system Tamagui (tous les composants bas niveau d'Alan).

    6. Alan Code Assistant

    Au-dela des designers qui codent en local

    Comment scaler ? Solution : un agent AI dans Linear (outil de product management d'Alan). Nom interne : Alan Goddison.

    Fonctionnement

    Assigner l'agent a une issue sur Linear. L'agent propose un plan. L'agent ouvre une pull request. Possibilité de trigger depuis Slack : fixe-le, PR automatique.

    Use cases

    Changements de copie, petits bugs visuels, micro-ajustements. Résultat : 1000+ taches gérées dans Linear par l'agent.

    7. 350+ PR mergees

    Q4 2024 : les chiffres

    Métrique

    PR mergees par designers et PM

    Résultat

    350+

    Métrique

    Designers onboardés et actifs

    Résultat

    35

    Métrique

    Taches gérées par Alan Code Assistant

    Résultat

    1000+

    Impact concret

    Bugs visuels corrigés sans attendre un ingénieur. Prototypes PM mergés directement ou utilises comme base. Velocite produit augmentée.

    8. Périmètre, pairing, DX

    1. Périmètre clair (front-end uniquement)

    Balance entre vélocité et complexité. Pas de risque back-end ou data model au départ.

    2. Engineering buddy indispensable

    Pairing avec un ingénieur : accompagnement, review, safety net. Pas pret à avoir des non-ingénieurs qui mergent seuls en prod.

    3. Developer Experience critique

    Simplifier l'environnement de dev pour les non-ingénieurs bénéficie aussi aux ingénieurs. Setup plus rapide, plus prédictible.

    4. Figma MCP = game changer

    Si vous travaillez dans Figma, le MCP est indispensable pour utiliser les designs directement dans Cursor.

    9. Les use cases concrets

    Laure (Product Designer)

    Change tous les écrans de login dans 4 pays et 2 produits différents. Ancien langage visuel remplacé. Sujet purement esthétique, difficile à prioriser, mais impactant : vu à chaque connexion.

    Ford (Motion Designer)

    Ajoute des micro-animations sur les composants du design system. Zero connaissance technique au départ.

    Louis-Auguste (Designer)

    Ajout d'animations d'emojis dans les chats.

    Autres contributions

    Changements de boutons pour cohérence globale sur l'admin dashboard. Lancement d'A/B tests. Fixes de copie.

    10. Setup fragile, qualité variable, review load

    Setup fragile

    Un bug d'infra, une PR mal testée : ça casse l'environnement de dev. Les non-ingénieurs ne savent pas forcément diagnostiquer. Messages Slack récurrents.

    Tester un changement est complexe

    Savoir comment accéder a un flow spécifique, un etat spécifique d'un membre : c'est 50% du travail d'un ingénieur. Pas évident pour un non-ingénieur ou pour l'AI.

    Risques de sécurité

    Donner acces à la codebase a des non-ingénieurs = risque. Aucun incident à ce jour, mais le risque existe.

    Qualite variable des PR

    Les non-ingénieurs n'ont pas les réflexes pour bien scoper leur travail. Garder des PR petites reste un défi.

    Agents hallucinent

    Quand on n'est pas tech-savvy, c'est difficile à détecter.

    Review load sur les ingénieurs

    Plus de PR = plus de charge de review. On voulait augmenter la vélocité, mais on ajoute du load sur les ingénieurs.

    "Mais ce sont de très bons problèmes à avoir."

    Tim, Engineering Lead, Alan

    11. Complexity assessment, Hopper

    Complexity Assessment

    Skill automatique dans Cursor qui se déclenche quand un non-ingénieur demande : je veux faire ça, est-ce que c'est compliqué ? Checks : y a-t-il du back-end ? Changement de data model ? Facilite de test ? Le skill catégorise la tache et peut arrêter le non-ingénieur avant qu'il ne se lance.

    Hopper : background coding agent maison

    L'environnement local ne scale pas pour tous. Solution : un agent AI qui tourne dans le cloud, sur des machines dédiées.

    Fonctionnalités de Hopper

    Interface de chat (comme Cursor, mais dans une app dédiée). Environnement de dev complet dans le cloud. Parallélisme illimité : lancer plusieurs sessions en même temps. Multiplayer : PM, designer, dev collaborent dans la même session avec l'agent. Controles de sécurité : interception des prompts avec données sensibles avant envoi au LLM. Integration de MCP : Figma, Notion, Slack.

    Stack technique de Hopper

    Serveur d'orchestration. Sandbox isolées avec la codebase complete. Harnais base sur Open Code (alternative a Cursor/Cloud Code). Appels aux LLM et MCP. Déclenchement depuis Linear, Slack ou n'importe ou.

    12. Comment unborder chez vous

    1. En local avec Cursor

    Si la codebase n'est pas énorme et que les gens sont un peu tech-savvy. Fonctionne très bien.

    2. Agents en background

    Si vous ne voulez pas construire votre propre solution. Outils existants : ONA, ARP, etc. Pas de setup en local requis.

    3. Figma MCP

    Si vous travaillez dans Figma : indispensable. Rationaliser le design system. Mapper avec Code Connect.

    4. Skills, templates et tests automatisés

    Développer des skills pour guider l'AI (complexity assessment). Templates de PR adaptés aux non-ingénieurs. Preview deployments sur chaque PR. Plus il y a de tests automatisés, plus l'AI peut tester elle-meme.

    Coûts

    Ne pas chercher à optimiser les coûts tout de suite. Écosystème évolue vite, incertitude. Alan est OK avec la non-prédictabilité des coûts pendant quelques mois. Plan team Cursor : 40$ de tokens par utilisateur, puis user-based au-dela.

    13. Leadership, confiance, chaos accepte

    Push du leadership

    Ujjala (Design Lead) + Alexandre Gerlich (Engineering Lead) + CEO : indispensable pour débloquer l'initiative.

    Confiance avec les ingénieurs

    Montrer qu'on prend en compte leurs frictions. Ne pas leur ajouter du travail. Memes standards de qualité.

    Accepter le chaos

    La roadmap a change en janvier 2024 après les vacances. L'AI évolue trop vite, il faut s'adapter. La roadmap va encore changer plusieurs fois dans l'année.

    Célébrer les avancements

    Encourager les gens à franchir la marche. Il y a un gap à franchir, mais il faut se lancer.

    "Ce changement arrive. Cette initiative permet aux Alaners d'etre contributeurs actifs du changement, plutôt que de le subir avec latence et panique en voyant Twitter."

    Tim, Engineering Lead, Alan

    14. ROI, resistance au changement, review fatigue

    Pourquoi Cursor plutôt que Cloud Code ou Codex ?

    Codex en CLI : pas une option pour des gens non tech-savvy. Cloud Code et Codex ont des apps desktop maintenant, mais pas de raison de bouger. Les gens sont onboardés sur Cursor, ça marche.

    Tout le monde a acces à la codebase chez Alan ?

    Oui, transparence totale. Tout le monde peut voir la codebase (meme ouvrir une PR depuis GitHub). Pas tout le monde l'a en local : focus sur les designers.

    Comment aborder les non-devs sur Git ?

    Éducation : tutoriels video, documentation Notion, guides. Différence de tech-savviness chez les designers. Abstraire Git derriere des skills Cursor : ouvre une PR, Cursor créé la branche, commit, push, ouvre la PR.

    Plan Cursor et rate limits

    Team plan : 40$ de tokens par user. Autorisation de dépasser en user-based. Réévaluation tous les mois.

    Code Connect facilement intégré ?

    Bon mapping entre Figma et le code du design system (peu de discrepancies). Cursor et Cloud ont aide à faire le mapping. Tous les composants ne sont pas mappés a 100%. Code Connect mappe les composants, mais pas les layouts.

    PM court-circuitent les designers ?

    Non : le design system garantit la cohérence visuelle bas niveau. Rules et skills en codebase pour best practices UI/design. PM principalement pour du prototyping. PR rarement mergees telles quelles en prod. Exception : outils internes (PM plus autonomes).

    Comment gérer les priorités ?

    Engineering buddy dit non en amont si pas de bande passante. Complexity assessment : si trop complexe, attente de 2 semaines pour review. Ingénieurs font des batches de review (1h tous les 2 jours). Petites PR de qualité visuelle : bénéfice énorme pour Alan.

    ROI et metrics

    Super complexe, pas de réponse valable aujourd'hui. Mesure naive : nombre de bugs fixes et UI fixes mergés. Surveys tous les 3 mois. Pas encore de métrique claire sur le ROI de l'AI.

    Review fatigue

    Problématique émergente. Écrire du code devient facile, plus de code a review. Explorations en cours : nouvelle interface de reviewing guidée par AI, différents tiers de review. Pas de solution encore, mais priorité des prochains quarters.

    Resistance au changement et impact psychologique

    "Printemps 2024, je me réveillais avec des cauchemars : j'ai perdu ma maison. Le fait de se dire on y va, on essaye, enlève énormément d'angoisse. Il faut se jeter dedans. C'est une problématique d'entreprise, pas seulement de designers. C'est un avantage compétitif. On n'a pas trop le choix."

    Laure, Product Designer, Alan

    "Réticence au changement : nos métiers changent, on va moins coder. Chacun a son avis là-dessus. On essaye de mesurer le feeling des ingénieurs, designers, PM. Ce qui marche le mieux : voir qu'on est tous dans la même galère, s'adapter ensemble, embrace le changement, trouver quelque chose d'éthique, où on s'y retrouve. Il n'y a pas de réponse unique."

    Tim, Engineering Lead, Alan

    15. Replay du live

    Vous recrutez ce profil ?

    TPC vous accompagne pour trouver des profils adaptés à vos besoins.

    Découvrez aussi notre pôle Engineering et son accompagnement dédié.

    Articles lies

    Tous les articles
    Tech

    Les 22 meilleurs outils JavaScript pour les Devs

    2 min
    Product

    Product Marketing Manager : missions, salaire

    1 min
    Recrutement

    Recruter un développeur : le guide complet

    2 min