#14 - Avec l'IA, n'importe qui peut éditer du logiciel. Y compris les conseils, y compris votre client.

Ce que j'ai vu cette semaine

Un cabinet de conseil s'est mis à éditer du logiciel.

Pas un outil interne pour ses consultants : un produit qu'il veut vendre à ses clients, en propre. Il n'avait rien développé de tel il y a quelques mois.

Ce n'est pas une anecdote isolée. C'est un déplacement de frontière que la plupart des dirigeants n'ont pas encore vu, et qui va se produire dans beaucoup de cabinets de conseil bientôt.

Pourquoi c'est possible maintenant

Éditer du logiciel supposait un capital technique. Il fallait des développeurs, du temps, de l'argent, et l'acceptation de brûler du cash, parfois beaucoup, avant d’avoir le premier euro de chiffre d'affaires ou encore d’atteindre la rentabilité. Cette barrière vient de s'effondrer.

Ce qui compte, c'est ce qui la remplace. La barrière à l'entrée n'a pas disparu : elle a changé de nature. Elle n'est plus dans la capacité à développer. Elle est dans la capacité à savoir quoi développer : quel irritant est assez récurrent, assez structuré, assez douloureux pour qu'un client paie chaque année pour le faire disparaître ? Qu’est ce qui est industrialisable ?

Or c'est exactement ce type de connaissance qu'un cabinet de conseil accumule depuis trente ans sans jamais l'avoir monétisé autrement qu'en jours-homme. Le conseil est un observatoire de problèmes récurrents. Il voyait les mêmes irritants revenir chez tous ses clients et n'avait qu'une seule façon de les traiter : refaire la mission.

L'asymétrie s'est inversée. Il semble aujourd'hui plus facile à un cabinet de conseil de devenir éditeur qu'à un éditeur d'acquérir trente ans de terrain métier.

Le mouvement est déjà lancé par le haut

Le 19 mars 2026, PwC US a lancé PwC One, une plateforme donnant accès à six services automatisés (détection d'anomalies, due diligence M&A, expertise fiscale) utilisables, selon Paul Griggs, patron de PwC US, sans qu'un employé de PwC soit dans la boucle. En parallèle, le cabinet fait basculer une partie de sa facturation du temps passé vers l'abonnement et le paiement à l'usage, et recrute davantage d'ingénieurs et de spécialistes data au détriment relatif des profils traditionnels. Aux associés qui penseraient pouvoir ignorer le mouvement, Griggs prévient qu'ils « ne resteront pas très longtemps ».

Deux précisions qui comptent, et que les résumés de ce lancement perdent souvent de vue. D'abord, l'accès sans intervention humaine est présenté comme valant « dans un premier temps » : c'est une porte d'entrée, pas un modèle sans humain de bout en bout. Ensuite, et c'est le plus intéressant, la menace que Griggs dit vouloir devancer est que les entreprises internalisent des prestations qu'elles externalisent aujourd'hui. PwC se désintermédie elle-même pour ne pas se faire désintermédier.

Sources : communiqué PwC US ; déclarations de Paul Griggs au Financial Times, reprises par Consultor le 24 mars 2026.

Ce que ça dit du marché : la polarisation

L'axe n'est pas le prestige. Ce que PwC industrialise (due diligence, fiscalité, détection d'anomalies) n'est pas du conseil de faible valeur. C'est du conseil à forte valeur mais codifiable.

Est codifiable ce dont on peut écrire la règle à l'avance : on connaît les intrants, les étapes, les points de contrôle et la forme du livrable. Ce qui varie d'une mission à l'autre, ce sont les données, pas la méthode. À l'inverse, n'est pas codifiable ce dont la valeur tient au jugement sur un contexte singulier : trancher entre deux stratégies quand aucune n'est démontrable, arbitrer au comex, décider ce qui compte dans une situation sans équivalent. Test simple : si je décrivais ma méthode entièrement par écrit, quelqu'un d'autre pourrait-il produire le même livrable ?

À croiser avec un second axe, la récurrence : le marché est-il assez large pour vendre souvent la même chose ?

Point contre-intuitif : la niche n'est pas protégée parce qu'elle résiste à l'automatisation. Elle est souvent parfaitement codifiable. Elle est protégée parce que le marché est trop étroit pour qu'un industriel du conseil descende l'y chercher, et parce que savoir quoi codifier suppose trente ans dans le métier et une forte expertise sectorielle.

Le milieu se vide. Un cabinet qui vend de la mise en œuvre standardisée à prix intermédiaire n'a ni l'avantage de coût de l'industriel, ni la profondeur du spécialiste. Il ne meurt pas d'être mauvais : il meurt d'être devenu indifférenciable d'un service automatisé.

Alors la question n'est plus « dois-je faire du logiciel ». Elle est : quelle part de ce que je vends est codifiable, et qui la transformera en logiciel en premier, moi ou quelqu'un d'autre ?

Pourquoi maintenant, et pas dans deux ans

Si la barrière technique à l'entrée est basse pour tout le monde, alors c'est d'avoir démarré avant les autres qui vous fait gagner. La fenêtre se refermera parce que les places seront prises : sur une niche métier étroite, il n'y a de la place que pour quelques acteurs, ceux qui auront accumulé les premiers des clients, de la donnée d'usage, une excellence opérationnelle et une réputation de produit.

L'objection évidente

Si l'IA a effondré le coût de développement pour vous, elle l'a effondré pour tout le monde. Y compris pour votre client.

Un outil bâti sur un cas d'usage simple, sans barrière particulière, est reproductible par la DSI de votre client en quelques semaines. Elle connaît le métier aussi bien que vous. Elle n'a pas d'abonnement à payer. Elle a même une bonne raison de le faire.

Ce qui vous a ouvert la porte l'a ouverte à tous. La barrière à l'entrée qui s'effondre est aussi une barrière à la sortie qui disparaît.

Une nuance quand même : peu de DSI se précipitent pour internaliser un outil métier. Recoder est devenu facile, exploiter ne l'est pas. Support, évolutions, sécurité, conformité, dette technique, sur un périmètre qui n'est pas leur cœur de métier et avec une backlog déjà pleine. Beaucoup préfèrent acheter et externaliser le risque. La menace n'est donc pas immédiate, elle est conditionnelle : elle se déclenche le jour où votre outil devient assez simple pour que l'internalisation ne coûte presque rien, ou assez critique pour que la dépendance dérange.

Sauf que l'outil n'est pas le business

C'est là que la plupart des analyses s'arrêtent, et c'est là qu'elles se trompent. Ce qui a de la valeur, ce n'est pas l'outil. C'est la boucle :

Le conseil détecte l'irritant récurrent → l'outil le digitalise → l'outil déployé chez le client révèle des besoins que personne n'aurait vus depuis l'extérieur → ces besoins nourrissent du conseil → et le conseil nourrit la version suivante de l'outil.

Un éditeur sait combien de clients ont ouvert son outil hier et combien de temps ils y ont passé. Il ne sait pas pourquoi ils l'ont ouvert, ni ce qui s'est dit en réunion juste avant. Un cabinet sait exactement cela, parce qu'il était dans la réunion. Mais quand la mission se termine, il referme le dossier et n'apprend plus rien de ce client.

Celui qui fait les deux voit ce qui se passe dans l'outil et pourquoi. C'est une connaissance que ni l'éditeur seul ni le cabinet seul ne peuvent accumuler.

Et c'est la vraie réponse au risque de copie. Votre client peut recopier votre outil. Il ne peut pas recopier votre position : la boucle suppose de voir plusieurs clients à la fois, et d'être assez proche de chacun pour qu'on vous dise ce qui ne va pas avant que ce soit écrit dans un cahier des charges. C'est ce qui vous permet de savoir qu'un irritant est structurel et non particulier. Et c'est aussi ce qui rend la vente possible : là où un éditeur doit faire ses preuves, vous avez une conversation. Votre client, lui, n'a qu'un point de vue : le sien.

La défense, ce n'est pas le code. C'est la position d'observation multi-clients et la relation qui l'alimente. Elle se renforce avec le temps, alors que le code se déprécie.

Ce que ça coûte quand même

Le prototype est devenu gratuit. Le logiciel, non.

Un outil que vos consultants utilisent tolère une ergonomie médiocre : le consultant est le mode d'emploi. Vendu seul, il doit être compris par quelqu'un qui n'a personne à côté de lui. Onboarding, support, documentation, versions, sécurité, dette technique. Rien de tout cela n'a été divisé par dix.

Et cela change votre P&L. Vous passiez d'une structure rentable dès le premier jour facturé à une structure avec de l'investissement, de la marge différée, de la récurrence à construire. Trois questions à trancher, entre autre, avant le premier euro :

• Le commissionnement. Vendre une licence à trois ans n'est pas vendre une mission. Qui touche quoi sur un revenu récurrent, celui qui signe ou celui qui suit ? À trancher avant l'embauche, pas après.
• Les actionnaires. Ils ont financé un cabinet de conseil. Comprennent-ils qu'ils financent désormais un éditeur, et sont-ils prêts à tenir jusqu'au point de rentabilité ?
• La valorisation. Un cabinet se valorise sur un multiple d'EBITDA, un éditeur sur un multiple d'ARR.

Le test

Deux questions, selon d'où vous partez.

Si vous êtes dans le conseil : que pourriez-vous vendre en logiciel ?

Regardez vos douze derniers mois de missions et cherchez le livrable que vous avez refait au moins cinq fois pour cinq clients différents. Puis posez-lui quatre questions :

1. Est-ce que je le refais à l'identique à 80 %, ou est-ce que chaque client a droit à du sur-mesure ? (Si c'est du sur-mesure, ce n'est pas un logiciel.)
2. Est-ce que le client en a besoin une fois, ou tous les ans ? (Sans récurrence, pas d'abonnement.)
3. Est-ce que je sais que l'irritant est général parce que je le vois chez plusieurs clients, ou est-ce que je le suppose ? (C'est votre position d'observation. Si vous ne l'exercez pas, vous n'avez pas d'avantage.)
4. Est-ce que ce que je vends, c'est le résultat ou l'expertise pour l'interpréter ? (Si c'est l'expertise, l'outil restera un outil interne, ce qui est une décision parfaitement valable.)

Un consultant sait reconnaître une mission récurrente. Il n'a pas forcément le réflexe de l'éditeur, celui qui regarde un livrable et voit une brique de produit. Deux prompts pour emprunter ce regard.

Prompt 1 : trouver les candidats

Prompt 2 : tester la codification

Vous venez de demander à une machine de faire votre travail à partir de votre seule méthode écrite. Comparez son résultat au vôtre.

S'il vous faut corriger des détails, un chiffre faux, une formulation maladroite, un point oublié, alors l'essentiel de la valeur était dans la méthode, et la méthode s'écrit. C'est industrialisable.

S'il vous faut refaire les arbitrages ou tout reprendre, parce que la machine a tranché là où vous auriez tranché autrement, alors ce que vos clients achètent n'est pas la méthode. C'est vous. Ça ne se vend pas en abonnement.

Les deux réponses sont bonnes à connaître. Elles ne mènent simplement pas au même métier.

Si vous êtes dans la tech : qu'est-ce qui est facilement réplicable ?

Prenez chacune de vos briques produit et demandez ce qui empêche votre client de la refaire lui-même cette année :

1. Reposez-vous sur une donnée qu'il n'a pas : un référentiel, un historique multi-clients, un benchmark ? (Défense solide.)
2. Sur un maintien réglementaire, une norme qui bouge et qu'il faut suivre ? (Défense solide : ce que le client achète, c'est que quelqu'un mette l'outil à jour à chaque évolution du texte. Reconstruire une fois est faisable, suivre pendant dix ans ne l'est pas.)
3. Est-ce que votre outil est connecté à ses autres logiciels, va chercher ses données quelque part et renvoie ses résultats ailleurs ? (Défense moyenne : vous n'êtes pas protégé par votre valeur, mais par le coût du débranchement. Ça retient un client hésitant, pas un client décidé.)
4. Sur le fait que c'était compliqué à développer ? (Cela dépend de la nature de la difficulté. Un développement long parce que le périmètre était vaste, les règles nombreuses ou les raccordements pénibles : ce n'est plus une défense, cela se refait vite aujourd'hui. Un développement long parce qu'il a fallu construire un savoir qui n'existait pas, des modèles, de la recherche, des ingénieurs spécialisés : la barrière tient toujours.)

Prompt 3 : faites réécrire votre produit par votre client

Regardez le point 4 de la réponse : ce que le DSI dit ne pas pouvoir reproduire. C'est votre défense, décrite par celui qui essaierait de vous remplacer.

Si cette liste est vide, ou si elle se résume au temps qu'il faudrait pour tout recoder, vous n'avez pas de défense. Vous avez un délai.

Si elle mentionne une donnée qu'il ne possède pas, une réglementation qu'il faudrait suivre en continu, ou une connaissance que vous tenez de vos autres clients, vous tenez quelque chose de solide. Reste à vérifier que c'est bien cela que vous mettez en avant quand vous vendez, et pas la liste de vos fonctionnalités.

Une variante utile : rejouez le prompt en remplaçant le DSI par un concurrent qui démarrerait aujourd'hui. Le DSI a d'autres priorités et un existant à gérer, le concurrent non. Si les deux réponses se ressemblent, ce n'est pas la copie qui vous menace, c'est le fait que n'importe qui puisse prendre votre place.

La question qui vaut pour les deux

Qu'est-ce que je sais, parce que je vois plusieurs clients, que chacun d'eux ne peut pas savoir seul ?

Si vous n'avez pas de réponse, votre outil n'est pas un produit : c'est un livrable de plus. Facturez-le dans la mission, il vous fera gagner du temps, et ne montez pas une filiale dessus.

Si vous en avez une, elle ne vaudra pas éternellement. Votre avantage tient à ce que personne ne l'a encore mis dans un logiciel. Ce que vous ne codez pas cette année, quelqu'un d'autre le fera, et il n'aura pas besoin de vous pour le vendre.

L'étape d'après : le faire

Un test dit s'il faut y aller. Il ne remplace pas le fait d'y aller. Et à ce stade, la seule chose qui répond vraiment à la question, c'est du code écrit par une petite équipe en quelques semaines.

Si vous venez du conseil, construisez la version la plus étroite possible de votre produit : un seul irritant, celui que le prompt 1 a classé en tête. Pas votre méthode complète, pas une roadmap. Mais assez fini pour qu'un client s'en serve seul, parce que c'est exactement ce que vous testez : la capacité de votre méthode à fonctionner sans vous dans la pièce.

Le signal est commercial, pas technique. Est-ce qu'un client l'utilise sans vous appeler, y revient la semaine suivante, et accepte de payer pour continuer ? Si vous devez l'accompagner à chaque usage, vous n'avez pas fait un produit, vous avez outillé votre conseil. Ce qui est utile, mais ce n'est pas le métier que vous étiez en train de choisir.

Si vous êtes déjà éditeur, cela se joue en deux temps.

D'abord, ce que le prompt 3 vous a appris. Si le DSI n'a rien trouvé de non reproductible, votre priorité n'est pas une fonctionnalité de plus : c'est de construire ce qu'il ne pourra jamais avoir. Un référentiel consolidé à partir de vos clients, un historique dont vous êtes seul à disposer, une veille réglementaire que vous entretenez. Sans cela, vous améliorez un produit que n'importe qui peut refaire.

Ensuite seulement, la réécriture. Une base ancienne accumule de la dette technique : du code qu'on n'ose plus toucher, des choix qu'on regrette, des évolutions qui coûtent trois fois ce qu'elles devraient. Tant que réécrire coûtait plus cher que maintenir, on faisait avec. Ce n'est plus le cas, et plusieurs éditeurs en ont profité pour repartir sur une base propre.

Dans les deux cas, le même principe : deux ou trois personnes, quelques semaines. Non par culte de la vélocité, mais parce que la question à ce stade est binaire, et qu'un projet à six mois vous donnera sa réponse trop tard, dans une année où les places se prennent.

Pour finir

Ce n'est pas une décision technique. C'est une question de positionnement : sur quel marché vous voulez être dans trois ans, et ce que vous vendez.

Août arrive. C'est probablement le seul moment de l'année où vous aurez le temps de regarder votre entreprise de loin. Servez-vous-en. Ce que vous savez faire que personne ne sait, ce que vos clients réclament depuis des années sans que vous ayez su le vendre autrement qu'en jours-homme : est-ce que ça ferait un produit ?

Et si oui, la vraie question arrive ensuite. Cette mue, avec les métiers nouveaux et les mois sans rentabilité qu'elle suppose, est-ce que vous avez envie de la faire ?

Répondre non est une réponse parfaitement valable. Ne pas trancher du tout, c'est laisser quelqu'un d'autre trancher pour vous.

Tu connais forcément quelqu'un que cette newsletter peut intéresser...

Je partage par mail

Je partage sur les réseaux sociaux

🔗 L'URL de la newsletter

Et si on t'a transmis cette newsletter, par ici pour t'inscrire et recevoir les prochains numéros.