8 leçons des équipes produit IA de la Silicon Valley

Fin octobre, je suis parti à San Francisco avec une grande question en tête :

Comment les startups de la Silicon Valley utilisent-elles l'IA pour construire leurs produits ?

Quelques mois plus tôt, Maud, de l'équipe communication Europe d'OpenAI, m'avait invité au DevDay, leur conférence annuelle à SF. Au début, je n'étais même pas sûr de pouvoir y aller. Chez Stellar, on était en plein rush, et quand on n'est que deux cofondateurs, chaque heure compte.

Mais l'idée d'assister à l'une des plus grandes keynotes tech au monde revenait sans cesse. Ça ressemblait au genre d'opportunité qui ne se présente pas deux fois.

J'ai donc décidé de faire de ce voyage quelque chose de bien plus grand : un documentaire complet sur la façon dont la Silicon Valley utilise l'IA pour construire des produits.

4 semaines plus tard, j'étais dans l'avion avec une nouvelle caméra dans mon sac, 150 mails de prise de contact envoyés et un planning de tournage assez fou. En 1 semaine, j'ai enregistré plus de 20 interviews avec des équipes d'OpenAI, DeepMind, Rippling, Gamma, Vercel, AnyShift, Fabi, Revo, Y Combinator et d'autres.

Le documentaire est maintenant en ligne sur YouTube. Mais je sais que certains d'entre vous préfèrent lire plutôt que regarder une vidéo d'1 heure. Dans cette édition, je décortique donc les 8 plus grandes choses que j'ai apprises sur la façon dont les meilleures équipes de la Bay Area utilisent vraiment l'IA dans leurs produits et leurs organisations.

‍

Leçon 1 : l'écart de scepticisme

La 1re chose qui m'a frappé quand j'ai commencé ces conversations à SF :
le niveau de scepticisme vis-à-vis de l'IA est bien plus bas que ce que je vois en Europe.

En France, j'entends encore des variantes des mêmes phrases :

• « L'IA ne passe pas à l'échelle. »
• « La qualité du code n'est pas assez bonne. »
• « C'est sympa pour des démos, mais pas pour la production. »

Dans la Bay Area, l'état d'esprit par défaut est presque l'inverse :

« Comment j'intègre l'IA dans tous mes workflows ? »

Chez Rippling, Ankur (Head of AI, ex-CTO de SAP) m'a expliqué que pour eux, l'IA est désormais la norme, pas l'exception. Ils ont même publié une « position IA » interne, où l'attente de base est que chacun utilise l'IA dans son travail au quotidien.

‍

Il estime qu'environ :

• 20 % des gens sont de vrais « power users » de l'IA
• 80 % sont « curieux de l'IA », prêts à l'utiliser mais avec besoin de cadre et d'accompagnement

Son rôle de Head of AI consiste moins à choisir des outils qu'à donner l'autorisation et le cadre :

• un message clair, venu d'en haut : « Par défaut, tu dois utiliser l'IA dans ton travail. »
• des règles sur ce qui est autorisé et ce qui ne l'est pas
• des rituels internes où les 20 % les plus avancés montrent leurs workflows à tous les autres.

Même chose chez Google DeepMind. Henri, PM sur le mode agent de Gemini, m'a dit que dans la Bay Area, les gens sont profondément convaincus par l'IA, alors qu'en France il ressent encore beaucoup plus de friction et d'hésitation.

‍

Le résultat est simple : ils ont une longueur d'avance complète en matière d'état d'esprit.
En Europe, beaucoup d'équipes débattent encore de savoir si l'IA est assez bonne.
À SF, les équipes optimisent déjà la façon de l'utiliser partout.

‍

Leçon 2 : les rôles s'effondrent

Mon deuxième grand apprentissage : l'IA fait exploser les frontières classiques entre les rôles.

Dans beaucoup d'équipes européennes, les rôles restent très « cloisonnés » :

• le PM écrit la spec
• le designer fait les maquettes
• l'ingénieur écrit le code
• chacun reste dans son couloir

Chez Rippling, c'est déjà différent :

• les designers utilisent Cursor pour modifier l'UI directement dans le code et ouvrir des PR
• les PMs utilisent l'IA pour tester les capacités techniques, faire des analyses et prototyper des idées sans attendre un ingénieur
• les ingénieurs s'appuient évidemment sur l'IA pour aller beaucoup plus vite côté technique

Ankur a décrit l'IA avec une métaphore que j'ai beaucoup aimée :

« L'IA, c'est comme un stagiaire super compétent qu'on t'aurait confié. » Ankur Bhatt, Head of AI chez Rippling

Tu ne te remplaces pas. Tu délègues du travail au stagiaire, et tu montes d'un niveau : plus de stratégie, plus de jugement, plus d'impact.

Ce même schéma est revenu dans plusieurs autres interviews :

• Chez DeepMind, Henri appelle ça « l'empathie pour le modèle » et explique que tout le monde touche désormais au prompting, au prototypage et à l'expérimentation : designers, PMs, ingénieurs.
• Chez Gamma, Deeni (Head of AI Product) m'a dit :

« La stack s'effondre. Les designers codent. Les PMs sont plus proches du repo. Les ingénieurs sont beaucoup plus tournés vers le produit. Le prototypage, le design, le cadrage et l'engineering se font désormais ensemble, pas dans une passation linéaire. »

‍

Chez Revo, Mehdi m'a dit que l'IA a transformé son équipe en « un groupe de créateurs pluridisciplinaires, pas une chaîne de production ». Les designers livrent des prototypes fonctionnels, les PMs écrivent du code, les ingénieurs modélisent les workflows produit.

Plus tu observes ces équipes, plus ça devient clair : les intitulés de poste restent, mais les frontières entre les rôles fondent.

‍

Leçon 3 : l'ambition comme réglage par défaut

L'une de mes conversations préférées a été avec Olivier Godement, Head of Platform & Business Products chez OpenAI (et ex-Stripe).

Je lui ai posé une question simple :

« Les équipes produit américaines sont-elles vraiment meilleures que les équipes européennes ? »

Sa réponse a été très claire :

• « Techniquement ? Non. » Les talents européens sont excellents.
• « En ambition ? Oui. » C'est là qu'est le vrai écart.

Il m'a expliqué que dans la Bay Area, quand une équipe lance un nouveau produit, elle vise rarement +10 %. Elle vise ×10, ×50, ×100 en impact, en utilisateurs ou en revenus.

Son raisonnement est assez brutal, mais juste :

« Construire un petit produit, c'est dur. Construire un produit énorme, c'est dur.
Autant viser le plus gros. » Olivier Godement.

En Europe, on a encore tendance à réduire l'ambition pour augmenter les chances de succès. À SF, ils gardent une ambition élevée et acceptent que le même effort puisse créer des résultats bien plus grands.

Tu le sens dans :

• la vitesse à laquelle ils livrent
• le type de produits qu'ils tentent
• la façon dont ils parlent de leurs objectifs

Et tu le sens particulièrement fort dans l'IA. La plupart n'essaient pas « d'ajouter une feature IA ». Ils essaient de repenser leur produit et leur catégorie autour de l'IA dès le premier jour.

‍

Leçon 4 : le développement produit est désormais circulaire

Autre grand changement : le cycle classique spec → design → dev → test → mise en production est en train de casser.

Chez Gamma, Deeni m'a dit quelque chose qui m'a vraiment marqué :

« Avec l'IA, il faut construire avant de comprendre. Tu prototypes, puis le prototype révèle le vrai périmètre. »

Comme les modèles ne sont pas déterministes et que leurs capacités changent sans cesse, on ne peut tout simplement pas tout définir en amont dans un Google Doc et attendre que la réalité suive.

Leur process pour une nouvelle feature ressemble plutôt à ça :

1. Ouvrir Cursor / Claude et construire un prototype en 1 à 2 heures
2. Jouer avec en interne
3. Se demander :
   • Est-ce qu'il se comporte de façon cohérente ?
   • Est-ce qu'il est utilisable ?
   • Est-ce qu'il est assez stable pour être mis entre les mains de millions d'utilisateurs ?
4. Seulement ensuite, écrire le « vrai » périmètre et affiner l'UX
5. Itérer vite en boucles serrées : prototype → test → ajustement → nouveau prototype

Le développement produit devient circulaire, rapide et vivant, et non plus linéaire et guidé par les documents.

Olivier, chez OpenAI, décrit quelque chose de similaire : beaucoup de PMs de son équipe n'écrivent même plus de PRD. Ils passent une heure à construire un prototype, le montrent aux clients et itèrent à partir de là. On ne peut pas faire semblant sur la qualité dans un prototype, ce qui force une réflexion bien plus profonde qu'un document joliment rédigé.

‍

Leçon 5 : de « l'IA en un coup » aux workflows agentiques

Autre grand changement entre 2024 et 2025 : les équipes passent d'une IA en un coup (« réponds à ce prompt ») à une IA agentique (« exécute ce workflow de bout en bout »).

Chez Vercel, Marcos m'a expliqué comment, en seulement un an, ils sont passés de simples « réponses de LLM » à des agents capables d'enchaîner des actions, de raisonner, de réessayer et de se corriger eux-mêmes.

Il m'a donné un exemple concret :

• Un collègue avait besoin de cohortes de rétention et d'un dashboard à partir d'un gros jeu de données
• Au lieu d'écrire du SQL et de débugger à la main, il a lancé un agent
• L'agent :
  • a exploré la base de données
  • a écrit une requête
  • l'a exécutée, a vu l'erreur
  • l'a diagnostiquée et corrigée
  • l'a relancée
  • et a fini par produire un dashboard complet, en 20 minutes environ, tout seul.

« Il y a un an, c'était impossible. Aujourd'hui, un agent peut faire ce qu'un analyste aurait mis deux heures à faire. » Marcos Grappeggia, Vercel

C'est un changement mental :

On ne demande plus seulement à l'IA de générer du texte ou du code.
On lui demande d'exécuter des tâches, de bout en bout, comme un coéquipier numérique.

‍

Leçon 6 : l'évaluation est la nouvelle compétence la plus difficile du PM

S'il y a une chose sur laquelle tout le monde était d'accord, de Gamma à Vercel en passant par OpenAI, c'est celle-ci :

« Construire une feature IA, c'est maintenant la partie facile. L'évaluer, c'est la partie difficile. »

Chez Gamma, Deeni m'a expliqué qu'à chaque sortie d'une nouvelle feature IA (génération de slides, outils d'édition, modèles d'image…), l'essentiel du travail n'est pas de livrer la première version. C'est de :

• définir à quoi ressemble le « bon »
• définir à quoi ressemble le « mauvais »
• trouver un moyen de mesurer les deux
• accepter que la réponse de l'IA ne soit jamais totalement déterministe

Elle l'a bien résumé :

« Un modèle peut être plus créatif mais moins fiable. Plus fidèle mais moins inspirant. Tu gagnes sur un axe, tu perds sur un autre. »

Chez Vercel, Marcos m'a parlé de 2 niveaux d'évaluation :

1. Les evals offline (avant le lancement) :
   • jeux de tests
   • prompts de référence
   • cas limites
   • garde-fous
2. Les evals online (après le lancement) :
   • métriques d'usage
   • taux d'acceptation
   • feedback humain
   • détection automatique de la baisse de qualité dans le temps

Et il y a un piège : dès que le modèle sous-jacent est mis à jour (ce qui peut arriver chaque semaine), tes evals peuvent casser sans prévenir.

Pour tous, l'évaluation devient une compétence clé du PM :

• cadrer l'intention
• définir la qualité
• concevoir le système de mesure
• continuer d'ajuster à mesure que les modèles évoluent

En Europe, on débat encore de l'outil d'IA à utiliser. Dans la Bay Area, ils optimisent déjà la façon de mesurer et de piloter les agents qu'ils déploient.

‍

Leçon 7. L'IA efface les frontières techniques

Autre chose que je ne m'attendais pas à voir aussi clairement : l'IA rend discrètement tout le monde « plus full-stack ».

Chez Fabi, Lei m'a dit qu'il vient du machine learning, pas du frontend. Mais aujourd'hui, avec l'IA :

• il peut corriger des bugs frontend
• toucher au backend
• et livrer des composants de bout en bout sans connaître en profondeur chaque partie de la stack

« L'IA te donne des compétences full-stack que tu n'avais pas au départ. » Lei Tang, CTO de Fabi.ai

Chez AnyShift, Roxane m'a décrit le revers de la médaille :
l'IA donne l'impression que tout est possible, donc le vrai risque, c'est d'aller trop loin.

Tu as envie de :

• automatiser la moitié d'un pipeline
• refactorer une énorme codebase
• construire un agent qui « fait tout »

Et tu peux le faire.

Mais tu risques de perdre des jours sur les derniers 10 %, là où une étape manuelle aurait suffi.

‍

Chez Fabi, ils l'ont même appris à leurs dépens :

• Lei a un jour poussé une PR de 1 000 lignes générée par l'IA pour corriger un seul problème
• Après la review, la vraie correction tenait en… deux lignes de code
• Le reste était du refactoring inutile que l'IA avait décidé de faire « pour rendre service »

Ils inscrivent désormais des garde-fous très explicites directement dans le repo et dans les prompts :

• « Ne cherche pas à tout refaire. »
• « Ne refactore pas de modules sauf si on te le demande explicitement. »
• « Fais le changement minimal nécessaire pour corriger le bug. »

Là encore, le schéma est clair :

• L'IA permet à chacun de toucher une plus grande partie du produit
• Mais sans contraintes fortes ni leadership, elle rend aussi la sur-ingénierie beaucoup moins chère et beaucoup plus tentante

‍

Leçon 8 : la nouvelle ressource rare → l'attention humaine

Mon dernier apprentissage est sans doute celui qui m'a le plus marqué personnellement.

Il vient de Mehdi, fondateur de Revo, un OS AI-first pour les organisations produit.

Il m'a dit :

« Dans un monde où l'IA peut presque tout faire, la ressource rare n'est plus la production. C'est l'attention humaine. » Mehdi Djabri, Revo.pm

L'IA va pouvoir générer plus :

• d'insights
• d'analyses
• d'options
• de roadmaps possibles

…que n'importe quelle équipe ne peut en absorber.

La contrainte se déplace donc :

• Avant : le temps, la capacité d'exécution, les effectifs d'ingénieurs
• Maintenant / demain : ce qu'on regarde, ce qu'on ignore, ce qu'on décide de faire, et comment on s'aligne autour de ça

Pour Mehdi, les humains ne seront pas « remplacés ».
Ils seront recentrés sur :

• la gouvernance
• l'intention
• la priorisation
• les valeurs
• le sens

Autrement dit :
la question clé n'est plus « Que peut faire l'IA ? » mais devient « Que voulons-nous que l'IA fasse pour nous ? »

J'ai quitté San Francisco avec le sentiment que c'est là la vraie frontière. Pas seulement utiliser l'IA pour aller plus vite, mais concevoir des organisations et des rituels qui protègent et concentrent l'attention humaine.

‍

Alors… qu'est-ce que tout ça veut dire pour nous en Europe ?

Passer une semaine dans la Bay avec des équipes comme OpenAI, DeepMind, Rippling, Gamma, Vercel, AnyShift, Fabi, Revo, YC et d'autres a rendu une chose évidente :
l'IA n'est pas une « feature ». Elle devient une nouvelle infrastructure du travail : mentale, organisationnelle et technique.

Le vrai écart entre l'Europe et la Silicon Valley, ce n'est pas le talent.
C'est :

• l'état d'esprit (ambition par défaut, usage de l'IA par défaut)
• la vitesse (prototyper, livrer, itérer)
• la discipline d'évaluation
• la volonté de laisser évoluer les rôles et les organigrammes

Et derrière tout ça, une question simple mais inconfortable :

Sommes-nous prêts à traiter l'IA comme une partie centrale de la façon dont on construit nos produits,
et pas comme un simple ajout cosmétique ?

Si cette newsletter te fait penser « OK, il faut qu'on regarde ça sérieusement dans notre orga produit & engineering », alors elle a fait son travail.

‍

📺 Regarder le documentaire complet

Si tu veux voir ces conversations et ces exemples en contexte (dont le DevDay, mon échange avec Sam Altman, Nicolas (YC), Romain (OpenAI) et toutes les équipes citées plus haut), tu peux regarder le documentaire complet ici :

Regarder le documentaire complet sur YouTube

‍