Comment l’IA fonctionne réellement dans les start-ups et les grandes entreprises.

Depuis l'arrivée de ChatGPT en novembre 2022, les entreprises ont compris qu'elles pouvaient tirer leur épingle du jeu grâce à l'IA générative. Mais comment font-elles ? Plus précisément, quelles sont les différences entre les schémas d’adoption et de déploiement de l’IA dans les petites entreprises et dans les grandes entreprises ? L'idée ici, n'est pas de prendre parti, mais de comprendre les dynamiques sous-jacentes et apprendre ce qu’elles révèlent sur la trajectoire de la révolution de l’IA.

N'ayant pas réussi à trouver une comparaison réfléchie sur la façon dont l’IA fonctionne réellement dans de petites startups versus de grandes entreprises, j'ai décidé de faire ma propre investigation, à partir de mes expériences au sein de Sirventia, à partir de ce que j'ai pu mettre en place chez mes clients et des témoignages que j'ai pu récolter.

Ce qui est assez clair lorsque l'on évoque l'adoption de l'IA en startup en comparaison avec l'adoption de l'IA en grand groupe, c'est qu'il y a deux conversations parallèles qui se croisent rarement. D'un côté, il y a des fondateurs de startups qui décrivent des workflows natifs IA comme si les contraintes des grandes entreprises n’existaient pas, et de l'autre côté, il y a les dirigeants d’entreprise discutant de cadres de gouvernance comme si la vélocité des startups n’était pas réelle.

Cet écart vient du fait de vivre dans des réalités différentes. Quand Dan Shipper chez Every construit des produits entiers par conversation avec Claude, et que Sarah, dans sa société SaaS de 400 personnes, met six mois à faire approuver GitHub Copilot, Dan comme Sarah sont rationnels. Ils optimisent simplement des objectifs différents sous des contraintes différentes.

En consultants des startups et des directeurs de grands groupes, j’ai observé les deux mondes. J’ai vu des fondateurs attribuer des tickets à des agents IA qui travaillent la nuit pendant qu’ils dorment. J’ai aussi vu des équipes en entreprise bâtir des processus d’approbation élaborés pour les outils d’IA pendant que leurs employés utilisent quand même discrètement ChatGPT dans leur navigateur. Les deux approches se tiennent dès qu’on comprend le contexte, mais personne n’explique vraiment ce contexte ni ce que chaque camp pourrait apprendre de l’autre.

Ce qui suit est cette comparaison manquante. Vous y trouverez :

— Comment fonctionnent réellement les startups nativement IA – Concevoir par la conversation, pas par le code
— La réalité des grandes entreprises – Pourquoi six mois pour approuver Copilot est parfois la meilleure option
— Stacks techniques – Outils spécifiques, coûts et raisons de divergence
— Flux de travail quotidiens – Des agents IA nocturnes aux sprints IA
— Coûts réels – 10 à 15 k$ par mois en crédits vs contrats entreprise
— Démarrages en 5 minutes – Que faire dès aujourd’hui, quelle que soit la taille
— Évolutions culturelles – Propriété du code, dynamique d’équipe, mémoire institutionnelle
— Problèmes d’intégration – Greenfield vs legacy de 2008
— Ce qui marche – Schémas qui réussissent partout

La réalité est que startups et grandes entreprises ont chacune compris des pièces importantes du puzzle de l’IA. Les startups maîtrisent la vélocité et le champ des possibles. Les grandes entreprises maîtrisent la soutenabilité et l’échelle. L’avenir appartient aux entreprises capables d’apprendre des deux approches. Mais d’abord, il faut voir clairement ce qui se passe réellement dans chaque monde, et non les versions simplifiées qu’on suppose de l’extérieur.

Le Guide de mise en œuvre de l’IA pour les entreprises

Si vous lisez ceci depuis une société de plus de 50 employés, vous connaissez la réalité : tout ce que je décris sur les startups nativement IA semble idéal jusqu’à ce que vous vous rappeliez que vous devez respecter la conformité SOX, protéger des données clients dont la fuite pourrait couler l’entreprise, et répondre à un CTO qui veut – à juste titre – savoir exactement où vont les données. Impossible d’adopter l’IA de manière improvisée quand vos clients font des audits de sécurité et que votre conseil d’administration attend des résultats trimestriels prévisibles. C’est pour cela que j’ai conçu ce guide de référence de 88 pages spécialement destiné aux entreprises de taille moyenne et aux grandes organisations qui mettent en œuvre l’IA.

L’objectif n’est pas d’aller vite en cassant tout, mais d’avancer méthodiquement sans rien casser. Ce guide détaille les outils réellement validés par les revues de sécurité, les cadres de gouvernance qui assurent la conformité sans étouffer l’innovation, les approches de conduite du changement adaptées à des ingénieurs expérimentés déjà échaudés par les effets de mode, et les architectures précises qui permettent d’expérimenter en toute sécurité tout en maintenant la stabilité attendue par vos clients.

Considérez-le comme une couche de traduction entre l’innovation des startups et la réalité des grandes entreprises : il reprend ce qui fonctionne dans le monde IA-natif et l’adapte à des environnements où « on corrigera en production » n’est pas une option. Car la vérité est que les grandes entreprises ne sont pas plus lentes à adopter l’IA par peur ou par ignorance, mais parce qu’elles s’attaquent à un problème fondamentalement plus complexe : transformer un avion en plein vol sans le faire s’écraser.

Comment fonctionnent réellement les startups nativement IA (et pourquoi l’IA en entreprise n’a rien à voir)

En parcourant des dizaines d’articles sur l’adoption de l’IA, j’ai constaté qu’ils passent tous à côté du même point : ils traitent la transformation IA comme un phénomène unique, comme si une startup de deux personnes à San Francisco et une entreprise de 500 employés dans l’Ohio jouaient la même partie. Ce n’est pas le cas. Loin de là.

J’ai pris conscience de ce fossé en comparant les pratiques de fondateurs de startups IA-first et de responsables produit cherchant à transformer des entreprises de taille intermédiaire. Les startups font tourner l’ensemble de leurs workflows d’ingénierie via Claude Code et Devin, traitant les agents IA comme de vrais employés, avec tickets Linear et évaluations de performance. Pendant ce temps, les grandes entreprises en sont encore… à débattre de l’autorisation d’utiliser ChatGPT sur leur réseau.

Ce qui est intéressant, c’est que ces deux approches sont parfaitement logiques dès qu’on comprend les contraintes propres à chacune. Le fondateur de startup n’est pas téméraire, et le directeur IT d’une grande entreprise n’est pas excessivement prudent. Ils répondent rationnellement à des réalités totalement différentes. Et ces réalités conditionnent tout, du choix des outils à leur définition même de ce qu’est l’IA.

Je veux donc analyser ce que j’ai observé en comparant ces deux mondes, car les enseignements de chaque côté sont plus subtils qu’on ne le dit. Les startups ont compris des leviers de vélocité que les entreprises doivent assimiler. Mais les grandes entreprises maîtrisent une adoption durable de l’IA que la plupart des startups, pressées, ne prennent pas le temps de voir.

La réalité du développement nativement IA

Commençons par Dan Shipper, car son approche chez Every illustre parfaitement la manière dont fonctionnent réellement les entreprises nativement IA. Every est à l’origine une société de médias, mais elle s’est transformée en véritable laboratoire de produits IA. Quand Shipper développe une nouvelle fonctionnalité, il n’ouvre plus d’IDE : il dialogue avec Claude Code sur ce qu’il veut, et la fonctionnalité émerge de la conversation.

Ce n’est ni de la paresse ni un raccourci. C’est une autre philosophie de création. Il parle « d’ingénierie cumulative » : chaque fonctionnalité développée avec l’IA rend la suivante plus simple, car l’IA comprend de mieux en mieux la base de code, les schémas et les préférences. Le code devient un organisme vivant qui se développe par le dialogue plutôt que par les frappes clavier.

Son équipe organise ce qu’ils appellent des Claude Code Camps. Des non-ingénieurs y expédient des fonctionnalités en production. La responsable marketing peut désormais créer des features produit. Le directeur des opérations conçoit des outils internes. Impensable dans une entreprise traditionnelle, mais chez Every, c’est la routine. Leur moteur de recherche Spiral a été entièrement construit de cette façon, en combinant ChatGPT pour le code initial, Clerk pour l’authentification, Supabase pour la base de données, Railway pour l’hébergement et l’API Claude pour l’intelligence artificielle. Ce n’est pas un prototype : c’est le produit final, utilisé et payé par les clients.

Claire Vo va encore plus loin chez ChatPRD. Elle assigne des tickets Linear directement à Devin, un agent IA capable de livrer des fonctionnalités complètes en autonomie. La première fois que j’ai entendu cela, je pensais qu’elle exagérait. Pas du tout. Devin travaille la nuit et pousse le code en pré-production pour révision le matin. Lorsqu’elle détecte un problème, elle ne le corrige pas elle-même : elle crée un nouveau ticket et le renvoie à Devin ou à un autre agent.

Son stack est volontairement varié : Cursor pour les API backend et les résumés, ChatGPT pour les conversions rapides (par exemple transformer des PDF en fichiers .ics), Lovable pour des prototypes « vibe-codés », et Gemini Flash spécifiquement pour l’analyse vidéo dans ses workflows de podcast. Elle utilise le Model Context Protocol (MCP) pour relier ces outils : ses agents peuvent interroger directement les données de Segment sans passer par Google Analytics. Les requêtes SQL se font via les connexions MCP, sans tableau de bord.

Le workflow paraît étrange vu de l’extérieur. Elle vérifie ce que Devin a produit pendant la nuit, contrôle les déploiements de pré-production, crée des tickets pour les problèmes, les assigne à différents agents IA, puis passe à la stratégie pendant que les agents s’occupent de l’implémentation. C’est comme diriger une équipe, sauf que la moitié de l’équipe n’a ni besoin de sommeil ni de négociation salariale.

Cette méthode s’étend jusqu’à la validation d’idées. Vo ne passe pas des semaines sur un MVP. Elle « vibe-code » un prototype dans Lovable ou v0 : elle décrit simplement l’ambiance du produit qu’elle veut, et l’IA en déduit les détails. Une heure plus tard, elle obtient quelque chose de suffisamment concret pour être présenté aux utilisateurs. S’ils n’aiment pas, elle n’a perdu qu’une heure. S’ils aiment, elle peut soit bâtir la version définitive, soit continuer à itérer jusqu’à ce que le prototype devienne le produit.

La qualité du code d’un tel prototype ferait frémir des ingénieurs traditionnels : fonctions trop longues, code dupliqué, abstractions minimales. Mais lorsqu’on peut régénérer une composante entière en quelques secondes en reformulant une demande, la notion de qualité change. Il ne s’agit plus de créer des abstractions parfaites conçues pour durer des années, mais de résoudre le problème du jour le plus vite possible, en sachant qu’on pourra tout réécrire demain si nécessaire.

La réalité des grandes entreprises face à l’IA

Prenons l’exemple de Sarah, directrice produit dans une société B2B SaaS de 400 employés. Son quotidien n’a rien à voir avec celui de Dan Shipper ou de Claire Vo.

Sa première tentative a été de donner accès à GitHub Copilot. Résultat : trois mois d’audits de sécurité, un mois de négociation avec les achats, deux mois de tests pilotes. Quand l’outil a enfin été déployé, la moitié de l’équipe utilisait déjà ChatGPT sur des comptes personnels, copiant-collant du code via leur navigateur, rendant l’audit quasi inutile.

Pourtant Sarah n’est pas déraisonnable. Son entreprise gère des données de santé, soumises à la conformité SOX et à des audits de sécurité exigés par ses clients. Une fuite via un outil d’IA et elle perd ses plus gros contrats. Les enjeux sont incomparables avec ceux d’une startup capable de pivoter en cas de problème.

Quand son équipe a enfin obtenu un feu vert, ce n’était ni Devin ni Claude Code, mais Azure OpenAI, verrouillé par des accords spécifiques sur la gestion des données et intégré dans l’infrastructure Microsoft existante. Les développeurs peuvent l’utiliser uniquement via des interfaces approuvées, avec enregistrement complet des prompts pour audit. Une IA avec roulettes, garde-fous et filet de sécurité.

Le défi culturel dépasse même le défi technique. Les ingénieurs seniors ont passé des décennies à perfectionner leur art. Ils ont bâti des modèles mentaux sophistiqués de l’architecture logicielle. On leur demande maintenant de déléguer à une IA qui commet des erreurs qu’eux-mêmes n’auraient pas faites en début de carrière. L’un d’eux lui a dit : « Je n’ai pas passé 20 ans à apprendre à coder pour finir prompt engineer. »

Sarah a tenté des ateliers IA, fait venir des consultants, créé du temps d’innovation pour expérimenter. L’adoption est restée inégale. Les juniors adorent, ils livrent plus vite que jamais. Les seniors s’en servent ponctuellement, surtout pour du code standard. Le middle management craint que l’IA rende leurs équipes redondantes.

Les succès se sont concentrés là où la douleur était déjà forte. L’équipe support, submergée de tickets, a adopté immédiatement la catégorisation et la rédaction assistée. L’équipe QA, toujours en retard, a sauté sur la génération de tests par IA. L’équipe documentation, chroniquement sous-dotée, est devenue en quelques semaines grande consommatrice. Mais l’équipe cœur produit ? Elle débat encore pour savoir si le code généré par IA est acceptable.