Nous sommes cinq, dont trois développeurs. Cette année, nous avons terminé 42 % de sujets de plus que l'an dernier et répondu à 388 demandes de clients, venues de près de 100 organisations. Le tout avec deux naissances dans l'équipe technique, soit plusieurs mois d'absence.

L'an dernier, nous racontions notre méthode : l'unanimité ou rien. Nous avons conservé ce principe. Mais nous ne mettons plus au vote les mêmes choses, et les agents IA ont pris une tout autre place dans notre code. D'où la question que se pose aujourd'hui toute équipe produit : quand l'IA accélère tout, qu'est-ce qui reste notre travail ?

Notre réponse tient en une phrase : l'IA accélère l'exécution, pas la décision.

Trois flux : corriger, polir, tailler

La qualité passe d'abord. Les bugs remontés par nos outils de surveillance et par le support sont traités en priorité, au fil de l'eau. Le mercredi, l'équipe met l'accent sur les corrections, pour ne jamais oublier que c'est la priorité.

Viennent ensuite les petites améliorations demandées par nos clients. Elles se règlent en quelques minutes ou quelques heures, sans vote, et polissent le produit comme un diamant. « Quand je voyais un truc qui allait pas et que je faisais un feedback, c'était corrigé en 24 heures. C'est royal », raconte Yacine Benameur, ingénieur MOEx chez Unanime Architectes.

Le vote, enfin, choisit toutes les six semaines les paris qui taillent une nouvelle facette du diamant : chacun représente environ deux semaines de développement pour une personne. Le lien avec le flux, c'est le problème de fond. Quand plusieurs demandes parlent d'un même problème, il devient une ligne parmi les 1 000 sujets.

De 1 000 sujets à 100 : préparer le vote

Notre liste a changé quatre fois de forme. D'abord des fonctionnalités classées par étape du parcours client. Puis une colonne par client clé, pour donner à chacun son poids réel, jusqu'à une matrice de 765 lignes que plus personne ne votait sérieusement. Puis 100 lignes préparées avec l'IA, l'impact et la confiance notés pour chacune. Aujourd'hui, nous ne votons plus sur des fonctionnalités mais sur des problèmes formulés, avec le résultat attendu et la raison d'agir maintenant.

Avant chaque vote, je reconstruis seul, avec l'IA, la liste des 1 000 sujets, puis j'en retiens 100. Je croise :

• les votes passés : pourquoi certains sujets sont passés et d'autres non (formulation du problème, résultat attendu, timing) ;

• les sujets clôturés dans Linear, leur formulation et leur taille, pour caler la granularité de la nouvelle liste ;

• la voix des clients : tickets de support, visios commerciales et de suivi client, emails, pour sentir les préoccupations du moment et reprendre leur vocabulaire ;

• l'usage réel, fonctionnalité par fonctionnalité, pour repérer succès et échecs ;

• nos veilles : bibliothèques techniques, SaaS B2B horizontaux et IA par brique produit, contech, activité de nos clients ;

• la stratégie : deals qui peuvent accélérer la roadmap, decks de board et direction produit.

Je reformule les sujets puis je classe avec plusieurs méthodes de scoring, comme RICE. C'est ma façon de rester proche du produit et des clients. Ensemble, nous passons ensuite de 100 à 10.

De 100 à 10 : le vote

Toutes les six semaines, le lundi de 9 h à 10 h 30, les cinq membres de l'équipe fixent les engagements produit de la période.

1. La synthèse : je présente les contraintes nouvelles et un Top 100 ordonné.

2. Le vote : chacun classe chaque ligne en Now, Next ou Later, avec un motif s'il le souhaite (valeur, timing, périmètre, preuve, capacité).

3. Le tri : Now vaut 2 points, Next 1, Later 0. Dix à douze sujets font l'unanimité.

4. La revue : on vérifie qu'on a compris la même chose et on estime l'effort, de XS à XL. Un XL est disqualifié ou découpé.

5. Le choix : chaque développeur prend trois sujets, en affine le périmètre et les ordonne.

6. L'offre : on choisit l'offre cible et on écrit la fonctionnalité telle qu'elle apparaîtra dans la grille tarifaire.

Les compteurs repartent à zéro à chaque vote. Un sujet régulièrement mal noté est mal formulé : on le reformule. Un sujet qui monte, redescend puis remonte est souvent un effet de mode.

Au dernier vote, 11 sujets ont fait l'unanimité, et l'équipe a posé 293 motifs de « pas maintenant ». Le timing arrive en tête (83), devant la preuve (72), la valeur (70) et la capacité (56) ; le périmètre ferme la marche (12). Nos désaccords portent sur le « quand », rarement sur le « quoi ».

Quand ils portent sur le « quoi », le problème demande un nouveau travail de découverte. Le PDF de preuve en est né : nous ne comprenions pas pourquoi certains téléchargeaient le PDF pour l'envoyer à la main depuis leur messagerie. Les entretiens ont fait apparaître plusieurs problèmes derrière ce même geste, et nous avons pu avancer sur certains.

Dix paris : deux semaines, une vidéo

Nous parlons de pari parce qu'un problème a toujours plusieurs solutions, et chaque solution plusieurs façons d'arriver jusqu'à l'utilisateur. Le développeur ne part donc pas deux semaines en tunnel. La première semaine, il présente sa solution dans une courte vidéo et recueille l'avis de l'équipe. La seconde, il intègre les retours et approfondit l'axe le plus prometteur. C'est là que l'équipe apprend en fabriquant.

L'IA dans le code : l'output n'est pas le produit

La grande évolution de l'année est venue du code. Les tickets sont rédigés pour être confiés à des agents IA et l'humain vérifie.

Les agents ont d'abord changé les chantiers de fond. Migrer une bibliothèque de composants d'interface obligeait à repasser sur une grande partie du code : un travail pénible, qui traînait des mois et laissait le produit avec deux styles. Les développeurs le lancent désormais d'eux-mêmes, sans arbitrage. Le travail de fond (tests, outillage, migrations) a plus que triplé, les bugs corrigés ont presque triplé, et la qualité monte. Linear fait le même constat à plus grande échelle : son agent corrige plus de mille tickets par mois, surtout de petits problèmes. Les problèmes difficiles restent difficiles.

Et le mouvement s'accélère. La semaine dernière, l'équipe a terminé 81 sujets, près de deux fois son rythme de septembre ; la moitié ont été résolus moins d'un jour après leur création. Ce n'est pas près de s'arrêter, pour deux raisons : les modèles frontière progressent à chaque version, en performance comme en coût, et nous apprenons à mieux orchestrer les agents, à automatiser nos boucles et à concevoir avec l'IA.

Pourtant, notre changelog compte toujours une ou deux nouveautés par semaine. Ce sont les améliorations et les corrections qui ont augmenté. Mais chaque nouveauté s'attaque à un problème plus important, avec un périmètre plus large qu'avant : import de vos comptes rendus, recherche, PDF de preuve, création d'un document depuis une note. Nous pouvons faire de plus gros paris, et notre Top 100 doit changer de granularité en conséquence.

Karri Saarinen, cofondateur de Linear, le formule ainsi : le travail produit deux choses, le produit et ce qu'on apprend en le fabriquant. L'industrie est obsédée par l'output, alors que les clients n'achètent pas des lignes de code. Si l'IA exécute à la place de l'équipe, on sépare l'exécution de l'apprentissage, et l'avantage se dilue. Notre règle : nous confions aux agents ce dont on apprend peu, jamais le choix de ce que nous construisons. C'est en débattant du quoi, du comment et du pour qui que l'équipe comprend ses clients. Et même le jour où les agents sauront tout coder, c'est nous qui répondrons de ce que nous livrons.

Le temps gagné ne sert donc pas à produire plus, mais à rester près des clients et à soigner la qualité. Ce que l'IA fait pour nos clients sur le chantier, supprimer le pénible pour rendre l'attention, elle le fait aussi pour nous.

Où le travail s'est porté

Nous avons classé les 2 069 issues terminées depuis septembre 2024 selon les étapes de notre produit : la note, le document, le partage, l'archive, et les passages de l'une à l'autre.

L'an 1 a posé les fondations : l'app mobile, le doc, le partage. L'an 2 a déplacé l'effort vers le document et vers les passages d'une étape à l'autre : import de vos comptes rendus, « Créer une suite » et fusion des notes. Les améliorations de l'existant ont presque doublé, quand les nouvelles fonctionnalités ont légèrement baissé.

Les blocs métiers résument ce choix. Nous construisons les briques (tâches par entreprise, présence, avancement, effectif), et l'IA y répartit ce qui s'est dit en réunion. Elle sait aussi n'en ajouter aucune : souvent, la bonne interface est une phrase.

Un chiffre nous a surpris. La part du travail consacrée aux notes a été divisée par deux, d'abord parce que le développeur qui en a la charge a été absent une bonne partie de l'année. C'est pourtant l'année où leur usage a décollé : quatre fois plus de notes en septembre que la moyenne de l'année. Exigence accrue, ou solution qui a tapé dans le mille ? Sans doute les deux. Une chose est sûre : nos paris les plus audacieux ont porté sur l'app mobile, et le plus audacieux a été de supprimer.

Choisir est le vrai travail

Plus il est facile de construire, plus il est facile de construire les mauvaises choses. Ronny Kohavi, qui a dirigé l'expérimentation chez Microsoft puis Airbnb, l'a rappelé chez Lenny Rachitsky : environ deux idées sur trois ne font pas bouger l'indicateur visé. Quand l'IA accélère tout le reste, c'est là que se joue la différence.

Cela suppose aussi de reconnaître l'échec d'une solution sans lâcher le problème. Trois leçons de l'année :

• Retirer vaut parfois mieux qu'ajouter. Le réflexe d'un responsable produit est de compléter une solution par de nouvelles fonctionnalités. Sur l'app mobile, supprimer deux points d'entrée sur trois a eu plus d'effet que n'importe quelle fonctionnalité. Supprimer est une solution à part entière.

• Le point d'entrée compte autant que la fonctionnalité. Le bloc IA du document, qui reformulait les notes qu'on y glissait, n'a pas pris. La même capacité, proposée depuis la note avec « Fusionner au document », a beaucoup mieux marché. Les passages d'une étape à l'autre sont les plus délicats : on peut les prendre par plusieurs bouts, et rien ne dit d'avance lequel trouvera ses utilisateurs.

• Une bonne idée peut arriver au mauvais moment. Notre extension web ne prend pas, alors que tous les grands assistants d'IA en proposent désormais une. L'idée n'est pas fausse, le moment l'est. C'est pour cela que le timing domine nos « pas maintenant » : un sujet écarté aujourd'hui peut revenir au vote demain.

Karri Saarinen en tire une règle que nous avons faite nôtre : chaque fonctionnalité doit mériter sa place. Construire ne coûte presque plus rien ; garder une fonctionnalité coûte toujours, en interactions, en bugs, en support et en attentes des utilisateurs. Le vrai piège n'est pas l'échec, qu'on retire vite, mais la fonctionnalité qui réussit juste assez pour survivre.

Le contexte devient le produit

Reste une conviction, que Karri Saarinen formule mieux que nous : pour une équipe produit, le contexte devient le produit. La connaissance des clients, du marché, des décisions passées. C'est ce que notre rituel entretient.

C'est aussi une leçon pour notre produit. Sur un chantier, le contexte existe déjà : c'est le compte rendu, semaine après semaine, pendant 18 à 36 mois, partagé entre quinze à trente entreprises. Ce que nous faisons pour décider, nous le faisons pour nos clients : rassembler le contexte pour que l'humain décide mieux, et laisser à l'IA le répétable.

Ce que cette méthode a produit sur le chantier, et notre prochain grand pari, le lecteur, nous le racontons dans There is a loop.