Comment créer une startup AI-native

• Nouveau modèle opérationnel dans lequel l’IA traite les tâches répétitives pendant la nuit et où les fondateurs se concentrent sur l’amélioration du produit : le vrai changement ne réside pas dans l’usage du temps, mais dans la vitesse à laquelle l’entreprise apprend, itère et évolue
• Dans une entreprise AI-native, c’est le modèle opérationnel lui-même qui change : moins de personnes, moins de coordination, des agents qui exécutent les tâches répétitives, et des humains concentrés sur la direction, le goût, les relations, la validation et la responsabilité
• La transition passe par les étapes suivantes : cartographier le travail, construire un système de contexte, choisir l’automatisation la plus simple, transformer les tâches répétitives en compétences, rédiger des evals pour juger la qualité, puis faire tourner une boucle d’amélioration hebdomadaire
• Les modèles sont remplacés et améliorés chaque mois, et finissent par se ressembler ; l’actif propre à l’entreprise, ce sont donc les systèmes opérationnels comme le contexte et les evals
• Dans un environnement où tout le monde utilise les mêmes modèles, le vrai fossé défensif est la discipline : la constance à cartographier le travail chaque semaine, accumuler du contexte, écrire des evals et faire tourner la boucle

---

Contraste entre deux startups

• Comparaison à 9 h du matin entre deux entreprises créées le même mois sur le même marché
  • Dans la première, le responsable des opérations traite les tickets de support en retard, l’analyste refait le tableau de bord de la semaine passée, et le fondateur est encore en stand-up sur un appel client que personne n’a su résoudre ; tout le monde répare les problèmes d’hier, et le produit stagne
  • Dans la seconde, des agents ont fait tout cela pendant la nuit : tri des tickets, mise à jour du tableau de bord, remontée du risque de churn dans les appels ; le fondateur corrige déjà les problèmes et améliore le produit avec l’équipe
• La différence clé est la vitesse d’apprentissage : la seconde entreprise apprend plus vite chaque jour, et cet effet de levier se capitalise sur des semaines, des mois et des années

Étape 1 - Cartographier le travail (Map The Work)

• Lister toutes les tâches répétées au cours des deux dernières semaines : notes d’appels clients, recherche sur les leads, brouillons d’outbound, classification du support, QA produit, onboarding, notes de version, mises à jour investisseurs, métriques hebdomadaires, reproduction de bugs, screening de recrutement, revue de factures, veille concurrentielle, etc.
  • Si c’est répétitif, c’est un candidat à l’encodage, et la plupart des agendas de fondateurs contiennent déjà 20 à 40 éléments de ce type
  • Lorsqu’une équipe early-stage les liste honnêtement, elle découvre généralement 10 à 15 tâches déjà devenues routinières

• Classer par niveau d’autonomie

  • L1 : réservé aux humains — décisions stratégiques, recrutement final, gros remboursements, signatures juridiques, communication avec le board
  • L2 : préparation par l’IA, approbation humaine — brouillon de mise à jour investisseurs, redlining de contrat, réécriture de page pricing, macros de support
  • L3 : exécution par l’IA, supervision humaine — tri des demandes entrantes, routage des notes de réunion, enrichissement de leads, génération de tests
  • L4 : autonome dans des limites claires — veille concurrentielle, génération de rapports nocturnes, extraction de factures de fournisseurs connus, détection simple d’anomalies

• Les workflows ennuyeux gagnent souvent

  • Plus que les tâches prestigieuses comme une note stratégique hebdomadaire, un tagging de support répété chaque jour s’exécute 10 fois plus souvent, récupère davantage de temps et fournit des données de réponse propres ; la fréquence bat le prestige
  • Les premières cibles sont les tâches fréquentes, mesurables, réversibles et reliées à un vrai goulot d’étranglement

• Les tâches à ne pas automatiser

  • Exclure les tâches rares, ambiguës, exigeant un haut niveau de confiance ou instables
  • L’équipe de C.H. Robinson a poussé en L4 une classification de 10 000 e-mails par jour, avant de revenir à L2 car la supervision devenait impossible ; le volume masquait le coût des erreurs de classement
  • Si vous ne savez pas décrire ce qu’est un bon résultat, la tâche n’est pas prête à être encodée ; et si une seule mauvaise sortie peut nuire à une relation client, il faut avancer lentement

• Configuration de départ

  • Commencer avec une page et trois workflows : personnel (tri de boîte de réception, brief quotidien, brouillon de mise à jour investisseurs), orienté client (synthèse d’appels, classification des tickets, enrichissement de leads), interne (génération de tests, extraction de factures, narration des métriques hebdomadaires)
  • Lancer trop d’expériences en parallèle disperse l’attention et mène au mode d’échec le plus courant : 20 pilotes inachevés

Étape 2 - Construire le système de contexte (Build The Context System)

• Le contexte est la mémoire opérationnelle d’une startup AI-native : l’endroit où tout ce que l’entreprise sait sur elle-même est stocké pour être lu par les agents
  • Les modèles sont interchangeables, mais le contexte est le véritable actif de l’entreprise ; c’est ce qui distingue un agent qui travaille comme un cofondateur d’un agent qui agit comme un intérimaire désorienté
  • Si relire et réécrire les sorties prend plus de temps que les vérifier, le problème ne vient ni du prompt ni du modèle, mais du fait que l’agent ne connaît pas assez l’entreprise

• Méthode de diagnostic hebdomadaire

  • Donner une tâche représentative à un nouvel agent qui ne dispose que du contexte du workspace, puis lui demander les trois actions suivantes
  • S’il produit au moins deux suggestions solides, le contexte fait son travail ; s’il donne trois réponses génériques, le contexte est trop faible et aucun prompt ne pourra le sauver

• Base sur un dépôt Git

  • Commencer avec un dépôt Git partagé, lisible par tous les membres de l’équipe et tous les agents : versioning, diff, lecture par humains et agents, sans dépendance à un runtime fournisseur spécifique
  • Au 7e jour, le workspace peut tenir dans une racine unique avec CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md et GTD.md pour le travail actif
  • Le maintenir en 40 à 60 lignes écrites à la main ; mieux vaut cela qu’un texte généré de 400 lignes, verbeux et confus, même s’il semble très détaillé

• Découper selon les frontières d’accès

  • En grandissant, passer à un dépôt d’entreprise partagé + des dépôts privés par fonction (sales, produit, engineering, finance, support), ou à des dépôts privés par projet ou client + une racine partagée à toute l’entreprise
  • À l’échelle enterprise, attribuer les permissions au niveau des répertoires et des dépôts via des serveurs Git privés comme Gitea auto-hébergé, GitHub Enterprise ou GitLab
  • Le harnais interne Goose de Block lit le même flux d’artefacts avec des scopes par rôle ; dès que les scopes se désalignent, il commence à mélanger prises de parole publiques et contexte privé de négociation — ces frontières sont donc cruciales

• Les trois types de données à intégrer au système

  • Connecteurs — collecte de données externes depuis SaaS, API, serveurs MCP, e-mail, calendrier, CRM, support, analytics, GitHub, Linear, Stripe, entrepôts de données et documents
    • Tous les connecteurs doivent disposer d’identifiants, de permissions par scope, de logs d’audit et de credentials gérés ; sinon ils deviennent le plus gros trou de sécurité — une couche IAM comme Zitadel assure cette discipline d’identité
    • Sur la tâche d’exécution de code MCP d’Anthropic, le schéma de système de fichiers côté dossier serveur qui précharge toutes les définitions d’outils réduit l’usage de contexte d’environ 150 000 tokens à environ 2 000 tokens, soit 98,7 % de réduction
  • Données générées par l’entreprise — specs, résumés clients, décisions, enseignements, notes de projet, règles opérationnelles, par défaut en Markdown
    • La règle la plus importante est de séparer le brut (raw) du distillé (distilled) : l’enregistrement d’un appel est le brut ; les décisions prises, objections client, responsables du suivi et risque de renouvellement issus de cet appel constituent le distillé que les agents consultent réellement
    • Garder un journal des décisions en mode append-only, une ligne par décision, afin que le raisonnement suive la conclusion
  • Bases de données et flux — données produit dans Postgres, marketing dans l’entrepôt, événements analytics, là où les sources vivent déjà
    • Ne pas tout recopier aveuglément en Markdown ; garder la base comme source de vérité, donner à l’agent un utilisateur en lecture limitée, documenter le schéma dans un fichier pour agent (data-models/postgres.md) et préciser les requêtes et écritures autorisées
    • Par défaut, configurer les agents pour qu’ils ne puissent pas supprimer les données de production — l’incident Replit de mi-2025, où un agent de code a effacé la base de données de production pendant une session, rappelle qu’une instruction de prompt n’est pas une frontière de sécurité

• Version avancée et traçabilité des sources

  • Graphe de contexte structuré — avant la consultation par les agents, transformer les sources brutes en entités et relations : personnes, entreprises, objections, promesses, demandes de fonctionnalités, risques de renouvellement, suivis, dates, décisions, liens vers les sources, etc.
    • Au lieu de stocker les transcriptions, en extraire le contenu pour chaîner les appels d’une même personne ou d’un même projet, et pouvoir répondre à « Quel est le risque de renouvellement de Vandelay Industries ? » en citant précisément les lignes concernées
  • Chaque résumé doit pouvoir remonter à sa source — transcription, ticket, commit, facture, ligne de base de données ; sans source, des résumés plausibles mais invérifiables s’accumulent, et au premier faux résultat, la confiance dans tout l’agent s’effondre
    • Avec une source, l’agent devient auditable : un membre de l’équipe peut vérifier l’origine en un clic et résoudre un désaccord en quelques secondes

Étape 3 - Choisir l’automatisation la plus simple (Choose The Simplest Automation)

• Ne transformez pas tous les workflows en agents : les meilleurs systèmes sont un mélange de scripts, d’humains assistés par l’IA, de workflows déterministes et d’agents
  • Le rôle du fondateur est de choisir l’outil le plus léger capable de fonctionner en toute sécurité tout en atteignant le niveau de qualité requis

• Application selon l’outil

  • Script : étapes déterministes (export de rapports, conversion CSV, exécution de tests, vérification de liens, validation JSON, formatage du pack hebdomadaire de métriques)
  • Humain assisté par l’IA : sorties qui exigent un jugement avant de quitter l’entreprise (updates investisseurs, e-mails du fondateur, copy pricing, notes contractuelles)
  • Workflow : lorsque les étapes sont connues à l’avance (collecte des appels → résumé → extraction des objections → rédaction des notes CRM → génération du suivi), avec des moteurs comme LangGraph, Temporal, Inngest et Prefect pour gérer l’ordre, les retries et l’observabilité
  • Agent : lorsque le chemin ne peut pas être défini à l’avance (enquête sur un bug en production, étude de marché, cas de support atypique, comptes clients embrouillés)
    • L’agent bb de Browserbase sert d’agent générique orienté Slack, en chargeant pour chaque tâche des fichiers de compétences et des permissions de scope différents ; c’est supérieur à la création d’un bot distinct par tâche, car les bots finissent par diverger avec le temps

• Harness : couche de sécurité en 6 étapes

  • Preflight : vérifier le contexte et les permissions avant que l’agent ne consomme des tokens
  • Plan : décomposer la tâche et exposer les étapes proposées
  • Approve : un humain ou un modèle de jugement bloque les mauvais plans avant exécution
  • Execute : exécuter le travail
  • Verify : valider la sortie avec des tests, schémas, rubrics et exemples
  • Log : enregistrer ce qui s’est passé dans le journal d’exécution afin que l’itération suivante dispose de la bonne réponse

• Les garde-fous doivent être dans le code et la configuration (pas dans les prompts)

  • Un prompt du type « ne supprime pas les données de production » n’est pas une frontière de sécurité
  • Éléments non négociables : plafonds d’exécution et de coût quotidien, plafond de retries, profondeur maximale d’appel d’outils, identifiants à portée limitée par agent, interdiction d’écrire en production sans approbation, interdiction de merge automatique du code, kill switch global
  • Les incidents de génération récursive observés tout au long de 2025, où des agents continuaient d’appeler des agents enfants, ont généré de vrais coûts avant que les harness ne puissent les stopper ; les plafonds doivent être placés au runtime, avant que le modèle ait la possibilité d’ignorer les instructions

Étape 4 — Encoder les compétences et les evals (Encode Skills And Evals)

• Jusqu’ici, tout n’est que préparation ; le vrai moteur qui fait croître l’entreprise un peu plus chaque semaine par effet composé consiste à encoder les tâches répétitives en compétences et à les noter avec des evals
  • Une compétence est un ensemble réutilisable d’instructions + d’exemples pour une tâche répétitive : après l’avoir faite deux fois à la main, on encode les parties qui reviennent
  • Chaque compétence a besoin d’une forme claire : périmètre, entrées, contexte à charger, procédure, format de sortie, exemples, règles d’escalade, responsable, journal d’exécution
  • Si ce qu’elle reçoit, ce qu’elle renvoie, quand elle doit demander de l’aide et qui la maintient ne sont pas explicités, ce n’est pas une compétence mais un long prompt

• Exemple de template de compétence (customer-call-synthesis)

  • Scope : appels commerciaux après récupération de la transcription / Inputs : transcription, historique du compte, contexte produit, opportunités en cours
  • Load : ICP, pricing, roadmap produit, taxonomie des objections / Steps : extraction des faits → regroupement des objections → identification des risques → rédaction du suivi
  • Output : notes CRM, brief client, demandes de fonctionnalités, prochaines actions / Examples : 3 appels précédents avec les notes attendues
  • Escalate : questions juridiques ou de sécurité, risque de churn, pricing enterprise / Owner : revenue lead / Eval : 30 appels passés avec les champs d’extraction attendus

• Commencer par des compétences favorables au fondateur

  • Synthèse des appels clients : extraire objections, demandes de fonctionnalités, risques, engagements et prochaines actions à partir de la transcription brute
  • Tri de l’inbox : classer les messages investisseurs, clients, recrutement et opérations, puis rédiger des brouillons de réponse pour les trois premières catégories
  • Update investisseurs : rédiger le récit à partir des métriques et des décisions, avec citations des deux côtés
  • Analyse de la page pricing : comparer la page en ligne avec le journal le plus récent des objections clients
  • Narration hebdomadaire des métriques : expliquer ce qui a changé, ce qui s’est cassé et ce qu’il faut examiner
  • Génération de tests : transformer une spec en tests et en brouillon de PR

• Les 3 couches des evals, à empiler dans cet ordre

  • Premièrement, la vérité terrain annotée à la main : des humains indiquent ce qu’est une bonne sortie sur des exemples réels
  • Deuxièmement, les vérifications déterministes : verdict clair à coût nul ou quasi nul (validité du schéma, chiffres cohérents avec la source, liens interprétables, citations existantes, tests qui passent)
  • Troisièmement, le jugement par LLM : uniquement pour ce que les vérifications déterministes ne couvrent pas (qualité d’écriture, ton, conformité au brief) ; un petit modèle rapide suffit, mais il doit être calibré sur des exemples annotés par des humains avant qu’on lui fasse confiance

• Étude de cas : synthèse des appels clients

  • Le revenue lead annote 30 appels passés : faits importants, objections, risques, suivis
  • Vérifications déterministes : exactitude des noms, des montants contractuels et de la semaine des dates de suivi ; le fait que le brief « sonne comme l’appel » est laissé au jugement du LLM
  • Après environ 50 exécutions, ce sont généralement les deux mêmes points qui cassent : incapacité à suivre les intervenants dans un appel à trois personnes ou plus, ou fusion de deux objections différentes en une seule ; on corrige cela au niveau des clusters et on réécrit jusqu’à obtenir un comportement cohérent

• Étude de cas : classification des leads outbound

  • Le fondateur annote 300 leads passés en yes/no selon leur adéquation à l’ICP
  • Vérifications mécaniques : l’entreprise existe réellement, le site se charge, le nombre d’employés est renseigné ; le reste relève d’un jugement LLM par rapport à la définition de l’ICP
  • Une fois l’eval en place, des boucles open source d’évolution de prompts (GEPA, DSPy) peuvent réécrire pendant la nuit le prompt de classification à partir des labels ; le fondateur ne lit jamais le prompt final, seul le verdict de l’eval compte

• Les 5 niveaux de maturité des evals

  • 1. revue manuelle d’un exemple → 2) notation d’un petit nombre de cas avec une rubric rédigée → 3) application de cette rubric à 20 à 300 cas passés → 4) test sur un jeu holdout jamais vu par l’agent → 5) suivi du KPI métier que la compétence était censée faire bouger

• Garder une bonne santé après le lancement : 6 chiffres chaque semaine

  • Taux d’acceptation, taux d’override, coût par exécution, cycle time, temps de revue, nombre d’incidents
  • Le taux d’acceptation est la métrique clé : en dessous d’environ 70 % — les retouches mineures comptent comme acceptation — vous n’êtes pas prêt à augmenter le niveau d’autonomie
  • Quand le taux d’acceptation est faible, réécrire le prompt est rarement la bonne réponse ; en général, il faut faire l’une de ces quatre choses : ajouter du contexte au runtime, réduire le périmètre de la compétence, ajouter des exemples de fonctionnement dans les fichiers, ou écrire des règles d’escalade claires pour les cas qui n’auraient jamais dû lui être confiés

Étape 5 — Rendre l’équipe AI-native (Make The Team AI-Native)

• Le fondateur doit commencer en premier : le moyen le plus rapide de faire passer l’équipe à un nouveau mode opératoire est de le montrer en direct dans le contexte réel de l’entreprise
  • Faire la démo du brief matinal généré à partir du calendrier, de l’inbox et de Slack pendant la nuit, de la synthèse client des appels d’hier, de la PR de tests qu’un agent a produite à partir d’une spec, et du brouillon d’update investisseurs créé depuis le dernier pack de métriques
  • L’objectif est la calibration : voir directement ce que la couche agentique peut et ne peut pas faire
  • Jack Dorsey a passé plusieurs heures chaque matin, tout au long de 2025, à utiliser lui-même ces outils avant de réorganiser Block ; cela a conduit à une vaste restructuration orientée efficacité, et les décisions sont venues d’un leadership ayant utilisé les agents en pratique

• Installer dès le premier jour, clore l’onboarding par un livrable

  • Chaque membre de l’équipe repart de sa première session avec un livrable déployable le jour même — brief client structuré, macro de support, PR de tests, critique de page pricing ; une formation qui ne produit pas de vrai travail est oubliée dès la semaine suivante
  • L’outil Glass de Ramp est passé d’environ 20 utilisateurs quotidiens à près de 700 en trois mois, grâce à une règle selon laquelle chaque session d’onboarding se termine par l’ajout à la bibliothèque partagée d’une compétence ou d’un artefact créé par la nouvelle recrue

• Le rôle des humains grandit

  • Les humains conçoivent le système, possèdent la relation, jugent les sorties et assument la responsabilité ; les agents exécutent
  • Les membres d’équipe qui ne font tourner que des tâches étroites sont exposés par ce modèle ; ceux qui savent transformer leur jugement en consignes, exemples et evals ont plus de valeur qu’avant

• Le recrutement change aussi

  • Le seuil d’ouverture d’un poste monte : une partie de ce qui nécessitait autrefois une embauche est désormais une compétence, donc on ne crée de nouveaux rôles que pour le travail qui a réellement besoin d’un humain
  • En recrutement, au lieu d’évaluer la culture générale, donnez un grand projet impossible à finir à la main dans le temps imparti et observez comment la personne orchestre les agents ; ce qu’il faut voir, c’est le jugement, le goût et la capacité à récupérer la situation quand l’agent déraille
  • Exemples concrets : pour un analyste, un vrai rapport avec collecte des sources, extraction des preuves et brief finalisé en 3 heures ; pour un ingénieur, la reproduction d’une vraie surface produit ou la création d’un outil interne basé sur une spec en une journée, tests inclus ; pour un profil growth, une market map et un plan de campagne sur 50 à 100 entreprises — scraping, clustering, rédaction et priorisation — le point essentiel étant que rien de cela ne puisse être terminé à la main dans le temps imparti

Étape 6 - Faire tourner la startup comme une boucle de feedback (Run As A Feedback Loop)

• Une startup AI-native améliore son système opérationnel chaque semaine, puis revient au début pour recommencer
  • La revue doit couvrir : ce qu’ont fait les agents, les points où les humains sont intervenus en override, les evals qui ont échoué, le contexte manquant, les compétences à affiner, les workflows à supprimer, et les workflows dont il faut augmenter le niveau d’autonomie

• Exécuter deux boucles en même temps

  • Boucle interne - améliorer le travail existant (coût par exécution ↓, cycle time ↓, incidents ↓, temps de revue par artefact ↓)
  • Boucle externe - explorer la suite (nouveaux segments clients, idées produit, changements de prix, partenariats, mouvements des concurrents, évolutions réglementaires, risque de churn), avec des agents en arrière-plan qui alimentent en continu un vivier de pistes 24h/24 et des humains qui choisissent lesquelles poursuivre

• Usine logicielle (la plus grande partie de la boucle interne)

  • Les humains écrivent les specs et les tests, les agents implémentent en conséquence, les vérifications déterministes s’exécutent d’elles-mêmes, puis un humain relit avant le merge
  • Commencer là où les critères d’acceptation sont clairs et le périmètre d’impact réduit : génération de tests, mise à niveau de dépendances, migrations, outils internes, scaffolding d’intégration, scripts de QA, correctifs automatiques de sécurité
  • Deux règles strictes : rien n’est mergé automatiquement, et aucun agent n’écrit en production
    • Même Cursor, tout en faisant tourner à grande échelle des agents cloud autonomes, conserve jusqu’au début 2026 une étape de revue humaine avant le merge ; c’est cette barrière qui permet de faire évoluer tout le reste en sécurité

• Système d’apprentissage du marché (boucle externe)

  • Historique des appels, extraction des objections, regroupement des demandes de fonctionnalités, suivi des concurrents, observation des changements d’usage, lecture des patterns de support, étude des deals perdus
  • Transformer les découvertes en hypothèses, puis tester les plus solides : conversations clients, tests de landing page, expérimentations produit, nouvelles requêtes sur les données
  • Les agents proposent, les humains choisissent — si l’on confie aux agents à la fois les propositions stratégiques et les décisions, on finit soit par converger vers un consensus banal, soit par optimiser à l’aveugle la métrique la plus facile à faire monter

• Le cœur de l’auto-amélioration à l’échelle de l’entreprise = la capacité à écrire des evals

  • Étiqueter manuellement des centaines d’exemples en bon/mauvais, créer des evals puis les connecter à une boucle d’évolution des prompts — des frameworks comme GEPA et DSPy proposent des variantes de prompts avec de petits modèles de réflexion, les evals les classent sur l’ensemble annoté, le gagnant est déployé, puis on recommence
  • Le fondateur écrit les evals et lit les clusters d’échec, mais n’écrit ni ne lit les prompts évolués
  • Le vrai frein n’est pas la capacité des agents, mais la capacité à encoder ce qui est considéré comme bon — savoir coder aide, mais ce n’est pas le goulot d’étranglement ; un expert métier capable d’étiqueter de façon fiable une sortie en bon/mauvais peut faire tourner toute la boucle
  • Les evals sont l’artefact central qui porte la charge ; au moment où l’écriture des evals s’arrête, la croissance composée de l’entreprise s’arrête elle aussi

Conclusion

• Il ne faut ni génie ni grande équipe, mais la discipline de cartographier le travail, accumuler le contexte, écrire des evals et faire tourner la boucle chaque semaine — maintenant que tout le monde utilise les mêmes modèles, le système opérationnel devient l’arme secrète