Catégorie : Développement logiciel

  • Qu’est-ce qui fait encore entreprise à l’ère des agents ?

    Qu’est-ce qui fait encore entreprise à l’ère des agents ?

    Si vous dirigez une entreprise en ce moment, vous avez vu passer les démos. Vous avez peut-être même signé pour quelques-unes. L’IA agentique, boostée à l’IA générative, fait réellement ce qu’elle prétend faire. Elle prend en charge des tâches que l’automatisation classique laissait tomber, elle débloque des chantiers que tout le monde évitait, elle soulage des équipes qui faisaient du laborieux à longueur de journée. Ce n’est pas rien !

    Pourtant, quand on regarde ce qui se passe au niveau de l’entreprise, on reste sur sa faim.

    L’institut METR a publié en 2025 une étude randomisée qui a fait un peu de bruit. Des développeurs expérimentés, équipés des meilleurs outils du moment, travaillant sur leurs propres projets, se sont avérés 19% plus lents avec l’IA. Eux étaient persuadés d’aller 20% plus vite. L’écart entre la sensation et la réalité s’est maintenu même après qu’on leur a montré les chiffres. La même année, le MIT a publié « The GenAI Divide », un rapport construit sur l’analyse de trois cents déploiements en entreprise. Verdict : 95% des projets n’ont aucun impact mesurable sur le compte de résultat. On parle de trente à quarante milliards de dollars dépensés pour un zéro à l’arrivée.

    Un outil qui marche, dont tout le monde parle, et dont le résultat reste invisible à l’échelle où ça compte. Il y a quelque chose qui cloche, et ce quelque chose ne se règle pas en achetant plus d’agents.

    On automatise ce qui se voit, on rate ce qui compte

    Dans la plupart des déploiements que l’on observe à La Forge, l’IA agentique sert à faire disparaître des tâches. Traduire un document, extraire les informations d’un CCTP, générer une facture, rédiger une relance standard, produire un compte rendu de réunion. Je comprends l’attrait : c’est du laborieux qui saute, c’est visible, c’est chiffrable, les équipes sont contentes de récupérer du temps. L’erreur n’est pas là. L’erreur, c’est de croire qu’en automatisant ces tâches on a développé son métier.

    Une activité, c’est ce qui occupe une personne en poste dans sa journée. Un savoir-faire, c’est ce qu’une entreprise sait faire via ses équipes et que personne d’autre ne sait faire exactement comme elle. Ce sont deux choses différentes. La manière qu’a une équipe commerciale de qualifier un client dès le premier appel, le coup d’œil d’un chef de chantier qui sent qu’un devis a un problème avant d’avoir lu la dernière ligne, la façon dont un responsable R&D arbitre entre deux pistes qui semblent équivalentes sur le papier : tout ça, c’est du savoir-faire. Et c’est ça qui fait qu’on est choisi plutôt qu’un autre.

    Ce que l’IA agentique fait très bien, c’est automatiser des activités. Ce qu’elle ne sait pas faire, ou ne devrait pas faire, c’est remplacer du savoir-faire. Tacite, situé, incarné, il est souvent invisible même pour ceux qui le portent, et il ne se laisse pas coder dans un prompt. Quand on essaie quand même, on obtient une version dégradée, lissée, interchangeable. On prend ce qui faisait la différence et on le rend générique.

    Il y a pire. Quand on se contente d’automatiser les activités, on fige le modèle de travail qui les a produites, et ce modèle est le plus souvent obsolète. Steve Blank le formule avec une brutalité salutaire : une entreprise de plus de trois ans est morte. Il ne veut pas dire qu’elle n’existe plus. Il veut dire que ses activités ont été dessinées pour un monde qui n’est plus là, que ses processus traînent des contraintes qui ont disparu, et que personne n’ose les remettre en cause parce qu’on les regarde depuis trop longtemps pour les voir. Automatiser les activités de 2015 avec les outils de 2026, ce n’est pas moderniser. C’est accélérer un travail qu’il aurait peut-être fallu cesser de faire.

    Quand l’intelligence métier se dissout dans les outils

    Le deuxième effet est plus lent à apparaître, et c’est probablement celui qui coûtera le plus cher.

    Dans une organisation qui se met sérieusement à l’agentique, chaque équipe assemble ses propres workflows. Les commerciaux construisent leurs agents de qualification, de relance, de préparation de devis. Les ops montent les leurs pour prioriser les incidents et produire les comptes rendus. La R&D bricole des chaînes qui lui sont propres. Aucune de ces équipes ne fait ça mal, aucune ne cherche à saboter la cohérence globale. Mais chacune, en assemblant ses agents, en écrit une version locale du métier. Ce qu’est un bon lead, une bonne relance, un bon incident, un bon brief : tout cela finit incarné dans des outils montés séparément, par des gens différents, sans référentiel commun.

    L’intelligence métier qui était portée par les équipes et par la culture (c’est flou, mais c’est justement ça, la culture) se déporte alors progressivement dans les outils. Et comme les outils sont montés à la main dans chaque coin de l’entreprise, il n’y a plus rien qui les tient ensemble. On se retrouve avec une organisation qui commence à ressembler à un agrégat de freelances très bien équipés, qui partagent un logo, un bureau et une fiche de paie, mais plus grand-chose d’autre.

    La question que je pose aux dirigeants ces derniers mois est simple. Si vous retirez les agents que chacun s’est construits, qu’est-ce qui fait encore que votre entreprise est la vôtre ? Le nom ? L’actionnariat ? La façade ? Rien de tout ça n’est un actif défendable. Ce qui faisait singularité, c’était la manière : un geste partagé, une exigence collective, une façon de voir le client, une qualité reconnaissable entre mille. Quand cette manière n’est plus incarnée quelque part de cohérent, elle disparaît. Pas d’un coup, par dilution. Et quand on s’en aperçoit, il est déjà tard, parce qu’on n’a plus aucun lieu où aller la reprendre.

    Le vrai risque est que l’IA remplace les gens et qu’elle banalise les entreprises. Deux boîtes qui orchestrent leurs agents à partir du même catalogue d’outils, sur les mêmes API, avec les mêmes pratiques de prompt engineering, finissent par produire la même chose. L’avantage compétitif s’évapore au rythme où les outils se standardisent, et les outils se standardisent vite.

    Le MIT arrive par son chemin à un constat proche. Dans les 5% de projets qui produisent un impact réel, les réussites se concentrent là où les entreprises ont une doctrine métier claire en amont, où le déploiement s’intègre profondément dans les workflows existants, où les choix d’outillage sont faits de façon cohérente plutôt qu’empilée. Partout où chacun orchestre dans son coin, l’impact reste anecdotique et s’érode à mesure que les outils circulent sur le marché.

    Reprendre la main sur son métier

    Il n’y a rien de mystérieux dans ce qu’il faut faire, c’est juste exigeant et ça demande de résister à la pente.

    Avant de déployer un agent, il faut savoir quel savoir-faire on cherche à amplifier. Ce n’est pas la même question que « quelle activité puis-je automatiser parce que c’est techniquement possible ». La première oblige à nommer ce qu’on sait faire de singulier, à le rendre visible, à le mettre au centre. La seconde laisse le catalogue de l’outil dicter le chantier, et on finit par empiler des automatisations qui ne convergent vers rien.

    Il faut aussi arrêter de laisser l’outil décider de la manière de faire. Si un agent optimise une relance client à sa façon, et que cette façon n’est pas la vôtre, c’est sa façon qui devient votre métier. Vos clients achètent une manière, pas un workflow. Chaque fois qu’on accepte une suggestion par défaut sans la passer au filtre de ce qui fait votre identité, on cède un petit bout de ce pour quoi on est choisi. Il suffit de répéter ce geste mille fois pour se réveiller dans une entreprise qui ressemble à toutes les autres.

    Et il faut accepter que ce qui est automatisable sans perte n’est pas du métier. Traduire un texte, générer une facture, extraire un CCTP, produire un compte rendu : automatisez, vite et bien, sans regret. Mais ne vous racontez pas que vous avez transformé quoi que ce soit. Vous avez soulagé du laborieux, c’est utile, ça libère du temps, ça rend la vie plus simple à vos équipes. Ce n’est pas stratégique pour autant, et confondre les deux est précisément le piège qui mène aux 95% de la courbe MIT.

    Ce que nous faisons

    La Forge est un studio de produits IA, nous utilisons intensément ces outils, et nous sommes exposés au même risque que tout le monde. Nous nous posons la même question que tous les dirigeants : comment faire grandir les équipes et l’entreprise ?

    Nous avons fait un choix qui nous coûte du temps et de l’énergie. Nous construisons en interne un système qui cristallise notre manière de faire, notre méthode, notre vision du métier, notre exigence de qualité. Ce n’est pas un outil qui automatise notre métier. C’est un endroit où notre métier est écrit, partagé, corrigé collectivement, et où chaque agent que nous utilisons passe par ce filtre avant d’agir. Sans ce système, nous serions comme les autres : mille visions locales assemblées dans notre coin, aucune boucle de cohérence, une singularité qui fond à mesure qu’on déploie.

    Je ne vais pas le détailler ici, pas encore. Mais si le sujet vous parle, si vous sentez que dans votre propre entreprise l’intelligence métier commence à fuir dans des outils que personne ne maîtrise vraiment, venez nous en parler. C’est précisément ce que nous aidons à construire ailleurs.

  • Où est la valeur quand coder devient trivial ?

    Où est la valeur quand coder devient trivial ?

    La capacité à produire du logiciel se banalise. La valeur se déplace vers le contexte, la distribution et la responsabilité.

    Il y a encore deux ans, produire un logiciel demandait du temps, du talent et du capital. Aujourd’hui, n’importe qui peut sortir un prototype fonctionnel en quelques jours. Les outils de génération de code, les plateformes no-code et les modèles d’IA ont fait tomber la dernière barrière : celle de la fabrication.

    La question qui en découle est plus dérangeante qu’il n’y paraît :

    Si tout le monde peut fabriquer, où se trouve encore la valeur d’un produit logiciel ?

    La commoditisation du BUILD

    Steve Blank, l’architecte du mouvement Lean Startup, a posé un diagnostic il y a quelques jours avec sa brutalité habituelle : si votre startup a plus de deux ans, elle est morte car vos hypothèses de départ sont probablement obsolètes. Le MVP (Minimum Viable Product) ne prouve plus la compétence d’une équipe.

    Le goulot d’étranglement a quitté l’ingénierie pour remonter vers :

    • le discernement : savoir quoi construire, pour qui, et dans quel contexte,
    • la connaissance des usages et,
    • la distribution.

    Ce constat est vertigineux pour toute l’industrie du logiciel. Pendant des décennies, la capacité à produire du code de qualité constituait un avantage compétitif. Les équipes d’ingénierie étaient le moteur, le recrutement de développeurs la priorité absolue. Ce monde-là est en train de basculer.

    La bascule ne signifie pas que le code disparaît. Elle signifie que le code, seul, ne vaut plus grand-chose. Ce qui se commoditise, c’est la capacité à transformer une idée en artefact logiciel. Ce qui ne se commoditise pas, c’est tout le reste.

    L’intelligence est une commodité, le contexte est le produit

    Un ingénieur et entrepreneur du nom d’adlrocha a donné dans un article une formulation limpide de ce déplacement : l’intelligence (au sens anglo-saxon de « renseignement », la capacité à analyser et à produire du signal) devient une commodité. Accéder à des modèles capables de raisonner et d’exécuter des tâches complexes est de plus en plus facile et bon marché.

    Ce qui crée la valeur, ce n’est plus le modèle lui-même. C’est le contexte dans lequel il opère : les connexions à l’environnement, les données métier, les contraintes opérationnelles, les garde-fous de sécurité.

    Pour illustrer cette idée, prenons l’exemple des outils de développement de nouvelle génération. Le cœur de ces agents fait quelques milliers de lignes de code. Le reste est seulement du « contexte » : des fichiers qui décrivent comment activer telle ou telle capacité selon le besoin. C’est un système de plugins piloté par du contexte, pas par du code. Pour adlrocha, le produit, ce n’est plus le moteur. C’est l’environnement dans lequel le moteur tourne. On pourrait dire que la valeur est dans le dernier kilomètre.

    Cela a une conséquence immédiate sur la manière dont on pense la capture de valeur dans la chaîne de l’IA générative. La vision dominante place le hardware et les hyperscalers en haut de la pyramide, avec une couche applicative comprimée.

    Mais cette lecture est incomplète. Une couche est en train d’émerger au-dessus : celle du contexte, du runtime et des environnements d’exécution sécurisés. C’est cette couche qui va jouer le rôle qu’avait le SaaS dans l’architecture Cloud. La question n’est pas de savoir si cette couche va apparaître, mais qui va l’occuper.

    Probabiliste ou déterministe : la ligne de fracture ?

    David Chen, qui dirige la banque d’investissement technologique de Morgan Stanley, propose une grille de lecture complémentaire.

    Sa distinction est simple : il existe du logiciel probabiliste et du logiciel déterministe. Je ne suis pas fan de cette dichotomie car simpliste mais elle donne une clé intéressante.

    Résumer une réunion, préparer des notes, suggérer une réponse : si le système se trompe un peu, ce n’est pas dramatique. C’est le territoire du probabiliste, là où les agents IA excellent déjà. En revanche, calculer une paie, une taxe, une facture, ou opérer dans un workflow critique ne tolère quasiment aucune erreur.

    Imaginez un agent IA qui gère vos réservations de restaurant : s’il se trompe d’horaire, c’est agaçant. Imaginez maintenant un agent qui calcule vos déclarations de TVA : s’il se trompe, c’est un redressement fiscal.

    C’est dans cette seconde catégorie que la valeur résiste le mieux : les systèmes d’enregistrement, les processus métier critiques, la conformité, l’intégration aux systèmes d’information existants, la responsabilité opérationnelle. Pour David Chen, la valeur du software ne disparaît pas. Elle se recompose autour des endroits où l’erreur coûte cher.

    Cette ligne de fracture est déterminante pour comprendre quels produits logiciels vont survivre et lesquels vont se faire comprimer.

    Les produits qui n’apportent qu’une interface ou une couche d’organisation de service sont les plus exposés. Ceux qui sont ancrés dans des processus critiques, couplés à un métier spécifique, intégrés à un environnement réglementaire mouvant, sont les mieux protégés.

    Du logiciel-interface au logiciel-résultat

    Steve Blank introduit dans son analyse une reformulation qui mérite attention. Le MVP devient MPO : Minimum Productive Outcome. La recherche du Product/Market fit devient la recherche d’un AI Agent/Customer Outcome fit.

    Le glissement est profond. On ne parle plus de livrer une interface, mais de livrer un résultat. Le pricing suit : au ticket résolu, à la réunion organisée, au lead qualifié. Ce passage de « software-as-interface » à « software-as-outcome » redistribue les cartes. Les produits qui facturent l’accès à une fonctionnalité (le modèle du siège dans le SaaS) se trouvent en tension. Les produits qui assument la responsabilité d’un résultat dans la durée occupent une position plus défendable. Car promettre un résultat suppose de maîtriser le contexte métier, les contraintes opérationnelles, les intégrations, la conformité, bref, tout ce qui ne se génère pas avec un prompt.

    Les « sunk costs » qui restent des actifs

    La distinction la plus opérationnelle proposée par Steve Blank est peut-être celle-ci : il existe des coûts irrécupérables qui restent des actifs, et des coûts irrécupérables devenus des passifs.

    Dans la première catégorie : les données propriétaires, la connaissance client, les intégrations physiques ou réglementaires, les positions acquises dans un écosystème. Ce sont des formes de contexte cristallisé : de la valeur accumulée qui ne se reproduit pas en un week-end à coups de prompts.

    Dans la seconde catégorie : les grosses équipes d’ingénierie calibrées pour des cycles lents, le pricing par siège, les roadmaps orientées fonctionnalités plutôt que résultats. Ce sont des structures héritées d’un monde où la fabrication était le goulot d’étranglement.

    Prenons l’exemple d’une société comme Pennylane (dont je suis fan du produit). Ce qui protège cette plateforme de comptabilité, ce n’est ni le capital ni le compute. C’est l’accumulation de données comptables dans un environnement réglementaire mouvant. Une copie de cette plateforme est faisable. Mais, quand les règles changent en permanence, qui va suivre l’évolution pour mettre à jour cette copie ? Pas grand monde.

    Ce constat a une conséquence : la valeur d’un produit logiciel n’est pas le code mais son contexte cristallisé. Il s’agit de sa base installée, ses workflows éprouvés, ses données structurées, ses intégrations, ses relations avec les métiers, etc. Encore une fois, tout ce qui ne se génère pas avec un prompt et ne se copie pas en un sprint.

    La distribution, actif irréductible

    Quand tout le monde peut fabriquer ou copier vite, l’actif le plus rare n’est plus le code. C’est l’accès aux utilisateurs, la rétention, la boucle d’usage en place.

    Michel Lévy-Provençal explicite ce déplacement par quatre termes :

    • attention,
    • accès (réseau),
    • confiance et,
    • responsabilité.

    Et il ajoute un point clé : l’IA a une connaissance exhaustive du passé, mais elle ne sait rien de l’émergent. Les signaux faibles, le terrain, les intentions restent des richesses rares.

    La distribution ne se télécharge pas, ne se copie pas, ne s’achète pas en un clic. Elle se construit par la crédibilité, la présence, le réseau, la réputation. C’est un actif profondément humain dans un monde où la production devient algorithmique.

    OpenAI elle-même formule son « triangle stratégique » comme compute, distribution et capital. Deux de ces trois piliers (compute et capital) relèvent de la puissance financière. Le troisième, la distribution, relève du terrain.

    Ce que le produit logiciel devient

    Si l’on rassemble ces fils, le produit logiciel de demain ne ressemble plus à celui d’hier. Ce n’est peut-être plus une application monolithique vendue à la licence ou l’abonnement. C’est un peut-être un agent adaptable, piloté par du contexte métier, déployé dans un environnement d’exécution sécurisé, et facturé au résultat.

    Le cas échéant, le maintenir ne ressemblerait plus du tout à de la maintenance classique. C’est de la curation de contexte : quelles données injecter, quels garde-fous poser, quels agents orchestrer, quelle gouvernance appliquer.

    Le produit logiciel ne disparaît pas. Mais la part du code dans sa valeur diminue, tandis que la part du contexte, de la distribution et de la responsabilité augmente.

    Pour les acteurs du secteur, la question posée par Steve Blank reste la plus inconfortable et la plus nécessaire : si vous recommenciez aujourd’hui, avec les outils d’aujourd’hui et dans le marché d’aujourd’hui, que construiriez-vous réellement ?

    La réponse honnête à cette question est probablement le meilleur test de survie qui existe.

    Conclusion

    C’est précisément cette conviction qui guide notre travail à La Forge depuis 2020. Notre mission est de forger des produits IA qui démultiplient les savoir-faire et rendent leurs utilisateurs meilleurs dans ce qu’ils font. Pas de produire du code. Pas de livrer des interfaces. De transformer un savoir-faire métier en actif logiciel durable, ancré dans un contexte réel, distribué à des utilisateurs réels, et assumé dans la durée.

    Si la valeur quitte le code pour migrer vers le contexte, la distribution et la responsabilité, alors la question pour chaque organisation devient : qui va m’aider à cristalliser mon savoir-faire avant qu’il ne devienne reproductible par n’importe quel agent ?

    C’est à cette question que nous répondons, un produit à la fois 👍