Comment j'utilise Linear, Codex, Claude Code et GitHub pour livrer des expériences de growth

Une expérience de growth meurt en général dans l'espace entre une bonne idée et un passage de relais propre.

L'idée démarre nette : changer la question d'onboarding, tester une nouvelle promesse de landing page, ajouter un nudge de cycle de vie, resserrer le parcours de démo. Puis on la recopie dans un doc, on la résume dans Slack, on la traduit en tâches, on la répartit entre design, data, engineering et marketing, et elle perd lentement sa forme. Le temps que l'expérience soit livrée, plus personne n'est tout à fait sûr de ce qu'était l'hypothèse initiale.

C'est là que j'utilise Linear, Codex, Claude Code et GitHub ensemble.

Linear n'est pas l'endroit où les agents font le travail. Linear est l'endroit où le travail reste organisé. Je m'en sers pour la gestion des tâches et des projets : réception, cadrage, responsabilité, dépendances, critères d'acceptation et statut.

Les agents assurent l'exécution. Codex et Claude Code aident à coder, relire, tester et préparer les changements. GitHub est l'endroit où ces changements deviennent concrets : branches, pull requests, CI, revue et historique de merge.

Le propos n'est pas « des agents Linear font tourner l'expérience ». Le propos, c'est que Linear garde l'expérience lisible pendant que les agents font avancer l'implémentation à travers GitHub.

La boucle

Mon workflow compte six étapes :

1. Réception
2. Brief d'expérience
3. Graphe de tâches
4. Instrumentation
5. QA de lancement
6. Postmortem

Le rôle de Linear n'est pas de prendre la décision. Il garde le raisonnement visible, met en évidence les pièces manquantes et maintient chaque artefact connecté à la même hypothèse. Les agents de code travaillent à partir de cette structure plutôt qu'à partir de prompts lâches.

Étape 1 : Réception

La boucle commence par une seule issue Linear :

Tester si l'ajout d'une question sur « l'objectif de sommeil » avant le questionnaire de qualification augmente le taux de complétion.

Un système faible transforme cela en une tâche et perd le contexte.

Une issue Linear utile la transforme en questions :

• À quel segment cela s'adresse-t-il ?
• Quelle métrique définit le succès ?
• Est-ce un test de conversion, un test de qualification ou un test d'apprentissage ?
• Quel est l'effet minimal détectable ?
• Quelle métrique en aval pourrait se dégrader ?
• Qui doit approuver le copy, le tracking des événements et le lancement ?

Le premier livrable n'est pas une liste de tâches. C'est un énoncé de problème plus affûté.

Hypothesis:
If we ask users to choose their sleep goal before the screener, completion rate will increase because the flow starts with user motivation instead of clinical qualification.

Primary metric:
Screener completion rate

Guardrail:
Qualified lead rate should not decrease by more than 5%

Decision rule:
Ship if completion improves by 10%+ and guardrail holds.

Cela change déjà la qualité du travail. L'équipe ne débat pas d'un bouton ou d'un champ. Elle débat d'un mécanisme.

Étape 2 : Brief d'expérience

Je crée le brief à l'intérieur de Linear et je le relie à l'issue d'origine.

Je garde le brief ennuyeux :

• Contexte
• Hypothèse
• Audience
• Métrique principale
• Métriques de garde-fou
• Événements requis
• Variantes
• Responsable
• Relecteurs
• Checklist de lancement
• Règle de décision

Ennuyeux, c'est bien. Ennuyeux, ça veut dire réutilisable.

L'astuce, c'est que le brief reste vivant. Si la variante change, je veux que l'issue rende l'arbitrage visible : est-ce l'hypothèse qui a changé, ou seulement l'implémentation ? Si une métrique est ajoutée, est-elle principale ou de garde-fou ? Si le copy change, le message correspond-il toujours au mécanisme ?

Le brief devient la colonne vertébrale de l'expérience.

Étape 3 : Graphe de tâches

La plupart des suivis d'expériences cassent parce que le travail est représenté comme une checklist plate.

Les expériences ne sont pas plates. Ce sont des graphes de dépendances.

Pour ce test, je crée des issues liées comme :

• Rédiger le copy de la variante
• Concevoir l'étape d'onboarding
• Implémenter la variante frontend
• Ajouter les événements analytics
• Configurer l'expérience dans Statsig
• QA du déclenchement des événements
• Rédiger la note de lancement
• Surveiller les 24 premières heures
• Readout après le seuil d'échantillon

Chaque issue porte la partie du brief dont elle dépend.

L'issue analytics contient les noms d'événements. L'issue design contient l'audience et l'hypothèse. L'issue QA contient les métriques de garde-fou. L'issue de readout contient la règle de décision.

C'est toute la différence entre la gestion de projet et la mémoire de workflow.

Comment Codex, Claude Code et GitHub s'intègrent

Linear est le système de projet. Codex, Claude Code et GitHub forment la boucle d'exécution autour de lui.

J'utilise Linear pour définir le travail : l'hypothèse, les critères d'acceptation, les dépendances, le plan d'événements, la checklist de QA et la règle de décision. Cela donne aux agents de code un objet stable sur lequel travailler plutôt qu'un prompt vague.

Codex est là où je lance les pistes d'implémentation. Pour une expérience plus large, je découpe le graphe de tâches en issues Linear étroites et je laisse chaque piste travailler dans sa propre branche ou son propre worktree. Une piste peut câbler la variante frontend. Une autre peut ajouter le tracking d'événements. Une autre peut resserrer le copy, les tests ou la documentation. L'important, c'est que chaque piste rende compte à la même structure d'issues Linear : ce qui a changé, ce qui a été validé, ce qui est bloqué et quelles preuves existent.

Claude Code est utile quand je veux une seconde surface de code dans le terminal : relire la forme d'une implémentation, explorer un repo, ébaucher un plan de migration ou éprouver si le code correspond encore au brief d'expérience. Je ne le traite pas comme une source de vérité distincte. C'est une autre surface d'exécution pointée vers la même issue Linear.

GitHub est là où le travail devient relisable et livrable. Les pull requests rattachent le diff de code, le statut de la CI, les captures d'écran et la discussion d'implémentation. Linear garde le pourquoi. GitHub garde le changement exact. La boucle fonctionne quand la PR renvoie à l'issue Linear et que les preuves de validation reviennent dans Linear.

Le workflow ressemble à ceci :

Linear issue -> Codex / Claude Code implementation -> GitHub PR -> review + CI -> Linear readout

C'est ce qui rend le système durable. Linear ne remplace pas GitHub. GitHub ne remplace pas Linear. Codex et Claude Code ne remplacent pas le jugement. Chaque outil possède une partie différente de la boucle.

Étape 4 : Instrumentation

L'instrumentation, c'est là où les bonnes expériences échouent en silence.

L'issue Linear porte le plan d'événements avant l'implémentation :

Events:
- sleep_goal_step_viewed
- sleep_goal_selected
- screener_started
- screener_completed
- lead_qualified

Properties:
- variant_id
- sleep_goal
- traffic_source
- device_type
- market

Ensuite, chaque tâche d'implémentation peut être vérifiée par rapport au plan :

• L'événement a-t-il été ajouté ?
• Le nommage est-il cohérent ?
• Les propriétés sont-elles disponibles au moment du déclenchement ?
• L'analyste peut-il segmenter par variante, marché et appareil ?
• Le dashboard correspond-il à la règle de décision ?

Ce n'est pas glamour. C'est exactement le genre de détail qui détermine si l'expérience crée de la connaissance ou seulement de l'activité.

Étape 5 : QA de lancement

Avant le lancement, je tiens une checklist de QA spécifique à l'expérience, pas générique au produit.

Pour ce test :

• La variante s'affiche sur mobile et desktop
• Le choix de l'objectif persiste tout au long du questionnaire
• Le parcours de questionnaire existant fonctionne toujours
• Les événements se déclenchent dans le bon ordre
• Le bucketing Statsig est stable
• Le dashboard contient les métriques principales et de garde-fou
• Un responsable de rollback est assigné
• Une note de support est prête si les utilisateurs posent des questions sur la nouvelle étape

La décision de lancement se prend au même endroit que le travail. Pas dans une note de réunion. Pas dans un fil Slack qu'il sera impossible de retrouver plus tard.

Linear devient la source de vérité pour l'état de l'expérience.

Étape 6 : Postmortem

Le postmortem, c'est là où la boucle complète devient la plus utile.

La plupart des équipes rédigent leurs readouts comme des résumés ponctuels :

La variante B a amélioré la complétion de 8 %, non statistiquement significatif. Pas de lancement.

Ce n'est pas suffisant.

Un postmortem utile répond à :

• Que croyions-nous ?
• Que s'est-il passé ?
• Qu'est-ce qui a changé dans notre compréhension de l'utilisateur ?
• Que devrions-nous essayer ensuite ?
• Quelles issues, docs, événements, captures d'écran et dashboards appuient cette conclusion ?

Le résultat devient une mémoire réutilisable :

Learning:
Motivation-first onboarding increased early engagement but did not improve qualified completions. Users selected goals, but the added step created drop-off before clinical questions.

Next test:
Move goal selection after screener completion and use it to personalize follow-up copy.

Cet apprentissage ne disparaît pas dans un slide deck. Il est relié au prochain item du backlog.

Ce dans quoi cette stack excelle

Le meilleur usage de cette stack n'est pas « fais mon travail à ma place ».

C'est :

• Garder le contexte rattaché aux tâches
• Transformer des idées vagues en briefs structurés
• Repérer l'instrumentation manquante
• Créer le bon graphe de dépendances
• Préserver les règles de décision
• Rendre les postmortems réutilisables
• Garder la prochaine expérience connectée au dernier apprentissage
• Laisser les agents coder, relire et valider par rapport à une issue claire
• Laisser GitHub porter le diff exact, la revue, la CI et l'historique de merge

Voilà pourquoi Linear est intéressant dans un workflow de développement produit AI-native. Il se trouve déjà là où le travail se négocie. L'issue est l'endroit où produit, engineering, design, support, sales et marketing touchent tous au même objet.

Si Codex et Claude Code travaillent à partir de cet objet, ils peuvent faire plus que générer du code. Ils peuvent aider à garder l'implémentation alignée sur la raison même de l'existence du travail.

Le point plus large

Les équipes de growth n'ont pas besoin de plus d'idées d'expériences. Elles ont besoin d'une meilleure mémoire des expériences.

Elles ont besoin que l'hypothèse, les tâches, les événements, la QA, la décision et l'apprentissage survivent au voyage de l'idée jusqu'au travail livré.

C'est la boucle que je fais tourner avec Linear, les agents de code et GitHub.

Pas une checklist plus rapide.

Une meilleure mémoire de la façon dont l'équipe apprend.