Le goulot d'étranglement s'est déplacé

Pendant trente ans, fabriquer un logiciel a été la partie difficile. Elle coûtait cher, elle prenait des mois, elle mobilisait des équipes. Tout le reste de la chaîne, comprendre le besoin, arbitrer, décider ce qui mérite d'exister, se réglait plus vite que la construction elle-même.

Ce rapport vient de s'inverser. Assistée avec méthode, la construction se compte désormais en jours. Et brusquement, la partie difficile n'est plus là. Elle est en amont, et elle est en aval : savoir précisément ce qui doit exister, et vérifier que ce qui a été produit tient.

C'est un déplacement inconfortable, parce qu'il déplace la compétence rare. Hier elle était dans la capacité à produire. Aujourd'hui elle est dans la capacité à trancher. Une organisation qui se procure la vitesse sans se procurer le discernement construit simplement ses erreurs plus vite.

HORALIO vaut comme démonstrateur de cela. Pas de ce que l'intelligence artificielle promettrait un jour : de ce qu'elle permet déjà, à condition d'être dirigée.

Le mythe des 50 % de fonctionnalités inutilisées

Posons la question que tout le monde connaît sans jamais l'énoncer : qui utilise plus de la moitié des fonctionnalités des grands logiciels que nous payons ? De la bureautique la plus répandue aux gros logiciels de gestion, très peu de gens.

On achète des cathédrales. On les déploie, on forme les équipes, on paie chaque année, on les maintient. Et chacun, au quotidien, n'en emprunte qu'un tout petit couloir. La moitié restante, ce sont des menus jamais ouverts, des options jamais cochées, de la valeur payée mais jamais consommée.

Pourquoi l'a-t-on accepté ? Parce qu'il n'y avait pas d'alternative. Fabriquer un logiciel exactement taillé pour une entreprise coûtait si cher que seuls les très grands groupes pouvaient se le permettre. Pour tous les autres, il fallait le générique : conçu pour convenir à peu près à tout le monde, donc parfaitement à personne.

On payait pour une cathédrale, on habitait un couloir.

Ce mythe a un revers plus lourd, et c'est lui qui explique la suite. Chaque grande suite traîne des années, parfois des décennies, de code hérité, de compatibilités à préserver, de dette accumulée. Ce poids explique une large part des coûts. Il explique surtout pourquoi un éditeur, une fois le contrat signé, se retrouve incapable de répondre dignement à une demande particulière : le devis explose, le délai se compte en trimestres, ou la réponse tombe, « ce n'est pas prévu par le produit ». Toute une économie logicielle vit de cette rente de l'immobilisme.

Mais remarquez ce que cette question suppose. Pour construire un outil qui ne contienne que le couloir, encore faut-il savoir lequel c'est. Presque aucune organisation ne le sait. Elle a des intuitions, des habitudes, des plaintes récurrentes, rarement une cartographie. C'est ce travail, et non la programmation, qui décide de la réussite.

Ce que votre logiciel ignore de votre métier

La première chose que je demande en arrivant dans une organisation n'est pas « quels sont vos besoins ». C'est : montrez-moi vos fichiers Excel.

Ceux qui ne sont pas officiels. Ceux que quelqu'un tient à la main depuis trois ans, qui circulent par courriel, dont personne n'a jamais parlé au directeur informatique. Il y en a toujours. Dans un cabinet, dans une commune, dans une usine, il y en a toujours.

C'est là que se trouve le vrai cahier des charges.

Ce qu'on y trouve

Un tableur qui recense les dossiers avec, en colonne libre, une mention que le logiciel officiel ne sait pas stocker. Un champ « commentaire » où les équipes ont pris l'habitude d'écrire un code que tout le monde comprend et qu'aucun programme ne lit. Une convention de nommage, apprise oralement, qui porte une information capitale. Une double saisie que personne ne conteste plus parce qu'elle date d'avant tout le monde.

Ces fichiers ne sont pas de l'indiscipline. Ce sont les morceaux du métier réel, expulsés du logiciel parce qu'il ne savait pas les accueillir, et réinjectés à la main par des gens qui, eux, savent de quoi ils parlent.

Chacun de ces fichiers est une spécification gratuite, déjà rédigée, qui attend d'être lue. En une heure passée dessus, on apprend ce qu'aucun atelier de cadrage ne produirait en une journée.

Voilà l'explication du mythe des 50 %

Un logiciel du commerce n'apporte pas seulement des fonctions. Il apporte une façon de voir le métier, celle de son éditeur ou celle de son plus gros client. En l'installant, une organisation accepte de penser son propre travail avec le vocabulaire de quelqu'un d'autre.

Les menus jamais ouverts sont les objets d'une autre maison. Et ce qui manque ne disparaît pas pour autant : cela ressort dans les tableurs.

Le mot technique pour désigner cette façon de voir, celle de l'éditeur comme celle du client, est l'ontologie. Nous ne le réemploierons pas souvent. Ce qui compte n'est pas le mot, ce sont les questions qu'il recouvre, et elles sont très concrètes.

Les questions concrètes

Pour un cabinet d'audit, elles ressemblent à ceci.

Qu'est-ce qu'une mission, exactement, et en quoi diffère-t-elle d'un dossier ? Un dossier appartient-il à un collaborateur, ou est-il partagé ? Qu'est-ce qu'un collaborateur a le droit de voir du travail d'un autre ? Un temps saisi est-il toujours déclarable, et sinon qu'est-ce qui l'en empêche ? Et quand plusieurs taux pourraient s'appliquer à une même heure, lequel gagne ?

Cette dernière question paraît triviale. Elle ne l'est pas. Dans ce cabinet, la réponse suit un ordre strict, du plus particulier au plus général : un taux fixé pour un collaborateur sur un projet donné l'emporte sur un taux de projet, qui l'emporte sur un taux de client, qui l'emporte sur le taux général du cabinet.

Ce n'est pas un réglage technique, c'est une prise de position. Ce cabinet considère que le particulier prime toujours sur le général. Un autre pourrait décider l'inverse. Aucun logiciel générique ne pose jamais la question, et c'est pourquoi tant d'utilisateurs corrigent leurs chiffres à la main après coup.

Pourquoi il faut venir sur place

Voici la difficulté centrale, et elle explique pourquoi ce travail ne se commande pas par écrit.

Demandez à un associé ce qu'est une mission : vous obtiendrez une définition parfaitement claire, en une phrase, immédiatement. Passez ensuite deux jours dans son cabinet, et vous découvrirez plusieurs sortes de missions au comportement différent, dont certaines qu'il n'aurait jamais pensé à mentionner parce qu'elles vont de soi.

On ne l'obtient qu'en observant, en proposant une formulation approximative, et en écoutant la correction. Le « non, pas tout à fait, en réalité c'est plutôt... » vaut dix réunions.

Un exemple, et un critère qui vous servira

En cours de projet, le cabinet a demandé que plusieurs collaborateurs puissent intervenir sur un même dossier. Formulée ainsi, c'est une fonctionnalité : une case à cocher, un champ à dupliquer, deux heures de travail.

Ce n'en était pas une. Jusque-là l'outil tenait pour acquis qu'un dossier appartient à un collaborateur, et les règles de confidentialité découlaient de cette appartenance. Le cabinet nous signalait, sans employer ces termes, que dans sa maison un dossier est un objet partagé. Modifier cela obligeait à reprendre les droits, puis les vues, puis les cumuls.

Voici le critère, et il est utilisable dès demain dans n'importe quelle organisation. Quand une demande arrive, ne l'estimez pas tout de suite. Demandez d'abord jusqu'où elle se propage. La propagation est la signature. Confondre les deux, c'est bricoler une case à cocher dans la nuit et découvrir six mois plus tard que les accès ne protègent plus rien.

Ce que le cabinet possède réellement

Terminons par le point le moins évident, et le plus important.

Nous disons que le cabinet est propriétaire de son logiciel. C'est exact du code et des données. Mais la valeur durable n'est pas là.

Le code a une espérance de vie de quelques années, et la génération assistée rendra son remplacement presque indolore. En revanche, la manière dont un cabinet d'audit conçoit une mission, un temps déclarable, une règle de confidentialité vis à vis d'un confrère, évolue à l'échelle d'une décennie.

Ce que le cabinet possède réellement, c'est le modèle explicite de son propre travail, mis au jour, discuté, arbitré, puis inscrit dans une structure. Trois semaines ont été nécessaires pour l'obtenir. Le code qui l'exprime pourrait être régénéré en quelques jours à partir de ce modèle. L'inverse n'est pas vrai.

Et c'est aussi ce qui décidera de la suite. Un assistant automatisé branché sur rien produit des réponses génériques : plausibles, bien tournées, inutilisables. Le même, branché sur les objets réels d'une maison, sur ses règles et son vocabulaire, devient un outil de travail. La différence ne tient pas à la puissance de la machine. Elle tient à ce qu'on lui a appris du métier.

« Ultra simple », une difficulté redoutable

Un cabinet d'audit et d'expertise comptable voulait un outil de suivi du temps « ultra simplifié ». Toute la réflexion et toute la conception du produit se sont appuyées sur cette notion. Et il faut le dire d'emblée, parce que c'est contre-intuitif : l'ultra simple est multidimensionnel, et il est d'une difficulté redoutable à obtenir.

La simplicité n'est pas une caractéristique, c'est un résultat

On parle de la simplicité comme d'une qualité qu'on ajouterait, un vernis appliqué en fin de parcours. C'est l'inverse. La simplicité est ce qui reste une fois que toutes les décisions difficiles ont été prises.

Chaque écran dépouillé est le résultat d'une série d'arbitrages : cette option, on la retire. Ce cas particulier, on le traite par une règle par défaut plutôt que par une question posée à l'utilisateur. Cette information, on la déduit au lieu de la demander. Ce paramètre, on refuse de l'exposer même si quelqu'un le réclame.

Un logiciel riche, à l'inverse, est un logiciel qui n'a tranché sur rien. Il a reporté chaque décision sur l'utilisateur, en la déguisant en liberté de configuration. C'est infiniment plus facile à construire, et c'est précisément ce que produit un logiciel générique.

Les dimensions de l'ultra simple

Elles sont au moins cinq, et elles ne se réduisent pas les unes aux autres.

Simple à saisir. Un auditeur qui déclare son temps ne doit pas penser à l'outil, seulement à sa mission. Cela se mesure en nombre de gestes, en valeurs proposées par défaut qui tombent juste la plupart du temps, en absence de navigation.

Simple à apprendre. Pas de manuel, pas de formation. Cette promesse est falsifiable, et c'est ce qui en fait un bon critère : ou bien un nouveau collaborateur y arrive seul, ou bien elle est fausse. Elle impose que l'interface épouse exactement la représentation mentale de l'utilisateur, sans étape de traduction.

Simple à adopter. L'outil parle le vocabulaire du cabinet. Rien à convertir, rien à transposer. Une conduite du changement n'est nécessaire que lorsqu'on demande aux gens de penser autrement.

Simple à lire. C'est la dimension qu'on oublie systématiquement. Le responsable qui consulte n'a pas les mêmes besoins que le collaborateur qui saisit, et la simplicité du côté lecture n'est pas obtenue en réutilisant celle du côté saisie. Ce sont deux problèmes distincts.

Simple à maintenir. Moins d'options, c'est moins d'états possibles, donc moins de combinaisons à tester et moins de défauts. La simplicité visible produit une simplicité invisible, et c'est elle qui rend l'outil durable.

Pourquoi c'est difficile

Trois raisons, dans l'ordre croissant de difficulté.

Retirer exige de savoir. Chaque option supprimée est le cas particulier de quelqu'un. Décider qu'on peut s'en passer suppose de connaître la différence entre un cas réel et un cas imaginé, entre une exception qui se produit chaque semaine et une qui n'est jamais survenue. C'est très exactement le travail décrit plus haut, celui qui consiste à comprendre le métier réel avant de le représenter. On ne peut pas simplifier ce qu'on ne comprend pas ; on peut seulement l'appauvrir.

La simplicité remonte jusqu'à la structure. Elle ne se joue pas dans l'interface. Si le modèle sous-jacent conçoit mal le monde du cabinet, aucun écran ne pourra être simple : il faudra bien, à un moment, demander à l'utilisateur de compenser à la main ce que la structure ne sait pas représenter. Une interface compliquée est presque toujours le symptôme d'un modèle qui pense de travers.

Retirer demande de dire non. Ajouter est consensuel, gratifiant, et ne fâche personne. Retirer suppose d'expliquer à quelqu'un que sa demande ne sera pas satisfaite, et d'en assumer la raison. C'est un acte de gouvernance autant que de conception.

Et l'intelligence artificielle rend cela plus dur, pas plus facile

Voilà le point que je voudrais laisser au lecteur. Tant qu'ajouter une fonction coûtait cher, le budget arbitrait à notre place. La contrainte économique tenait lieu de discipline, et beaucoup de logiciels sont restés sobres pour de mauvaises raisons.

Quand la génération rend l'ajout presque gratuit, ce garde-fou disparaît. La machine ajoutera tout ce qu'on lui demande, immédiatement, proprement, sans jamais objecter. La simplicité cesse d'être une contrainte budgétaire pour devenir une pure affaire de jugement. Et un jugement qui ne s'appuie plus sur aucune résistance matérielle est beaucoup plus difficile à tenir. C'est, en une phrase, tout le sujet de ce retour d'expérience.

Les deux autres exigences

Une fois posée cette contrainte fondatrice, deux autres complètent le tableau.

Une personnalisation profonde. Chaque cabinet a ses types de missions, ses libellés, ses règles, ses dossiers. L'outil épouse l'organisation, pas l'inverse. Notons au passage la tension apparente avec la simplicité : personnaliser, c'est ordinairement multiplier les réglages. Elle se résout en amont : ce qui est personnalisé n'est pas un jeu d'options offert à l'utilisateur, c'est la structure elle-même, décidée une fois pour toutes avant la première ligne de code.

Et le point stratégique, le plus subtil : constituer un actif. Le vrai gisement n'était pas la saisie, c'était la donnée qu'elle produit. La traçabilité interne pour piloter les missions, savoir où en est un budget et quelle marge sort d'un dossier. La transparence client, pouvoir justifier le temps réellement requis sans jamais exposer coûts ni marges. Et surtout la fiabilisation des remontées réglementaires : un cabinet de commissariat aux comptes rend des comptes à sa supervision, et la qualité de ses déclarations dépend directement de la fiabilité des temps déclarés. Un suivi du temps rigoureux n'est pas un confort administratif, c'est un outil de conformité.

Voilà l'écart entre la demande et le besoin. La demande disait « saisir des heures, très simplement ». Le besoin disait « produire, sans effort perceptible, une donnée dont on répond devant un client et devant une autorité ». Ce ne sont pas les mêmes logiciels, et on ne trouve pas ce décalage dans un cahier des charges. On le trouve en écoutant.

Ce que nous avons refusé de faire vite

Reprenons l'épisode des dossiers partagés, mais du côté de la décision plutôt que du diagnostic.

Une fois comprise la nature du problème, il aurait été très facile de bricoler un contournement dans la nuit. La machine l'aurait produit sans broncher, et le lendemain matin la case aurait été cochée. C'est précisément ce que produit la vitesse laissée à elle-même : une satisfaction immédiate et une fragilité différée.

La bonne décision a été de suspendre, d'expliquer au cabinet pourquoi il s'agissait d'un chantier et non d'un réglage, et de le traiter comme tel. Cela a coûté des jours. Cela en a économisé beaucoup plus.

L'expérience, c'est savoir ce qu'on ne code pas tout de suite.

Cette décision est invisible dans le produit fini. C'est pourtant elle qui distingue un logiciel qu'on garde d'un logiciel qui s'effondre au premier changement. Et c'est le genre de décision qu'on ne peut pas prendre depuis l'extérieur, sur la foi d'un ticket.

Ce métier a un nom : l'ingénieur déployé chez le client

Ce que nous venons de décrire n'est pas une improvisation. C'est une pratique établie, qui porte un nom et possède une histoire : le Forward Deployed Engineer, ou FDE, que l'on peut traduire par ingénieur déployé chez le client.

Le modèle est né chez Palantir. Plutôt que de vendre une licence et de laisser le client se débrouiller avec l'intégration, l'entreprise plaçait ses propres ingénieurs au cœur des organisations, pendant des mois, pour construire avec elles les cas d'usage réels. Le pari paraissait coûteux et étrange. Il s'est révélé décisif.

Depuis, il est massivement repris. OpenAI a constitué son équipe en 2024, Anthropic a développé la sienne, Databricks, Scale AI et Google DeepMind ont suivi. Les offres d'emploi pour ce rôle ont bondi de plus de 800 % entre janvier et septembre 2025. Et au printemps 2026, Anthropic et OpenAI ont chacun lancé une coentreprise de déploiement en entreprise, chiffrée en milliards, entièrement bâtie sur ce modèle.

Le trait distinctif est une responsabilité de bout en bout. L'ingénieur qui cartographie le problème le premier jour est celui qui répond quand quelque chose casse en production six mois plus tard. C'est le contraire du consultant qui livre un rapport puis s'en va, et le contraire de l'intégrateur qui paramètre un produit qu'il n'a pas conçu.

Pourquoi tout un secteur converge-t-il vers cette organisation ? Pour une raison qui éclaire l'ensemble de cet article : un modèle générique donne des réponses génériques. La valeur ne surgit qu'une fois l'outil ancré dans le vocabulaire propre de l'organisation, ses objets, ses règles, ses cas particuliers. Cet ancrage n'est pas une affaire de formulation habile, c'est un travail d'ingénierie, et il exige d'avoir passé du temps sur place.

HORALIO est exactement cela : une application construite sur les missions du cabinet, ses libellés, ses dossiers, ses règles de confidentialité, ses obligations vis à vis de sa supervision. Les seize jours ne sont pas une prouesse de vitesse. Ils sont ce que produit quelqu'un qui a compris le terrain avant de commencer à construire.

La bascule : du générique cher au sur-mesure à coût adapté

La conséquence est concrète. La question n'est plus « quel logiciel générique se rapproche le plus de mon besoin ? », mais « quel logiciel dessine-t-on exactement pour mon besoin ? ». On ne choisit plus dans un catalogue, on commande un outil à façon, qui n'existait pas et qui n'existera que pour cette organisation.

Et de plus en plus, des outils qui ne se contentent plus de réagir (l'alerte, le seuil dépassé, la relance) mais qui préparent les décisions et remontent la bonne information au bon moment, au bon rôle. Le logiciel cesse d'être une contrainte que l'on subit. Il devient un partenaire taillé à sa mesure.

On peut raisonnablement anticiper ce que cela produira : non pas de nouvelles suites universelles, mais la naissance de nombreuses structures très légères, bâties sur un modèle hybride de conseil et de développement, entièrement centrées sur un client à la fois. Pas de produit universel à vendre, pas de dette héritée à traîner. On comprend une organisation, on lui taille l'outil dont elle a réellement besoin, on le lui laisse.

Posséder son logiciel, plutôt que le louer

Il y a un second renversement, moins visible, tout aussi décisif. D'ordinaire une entreprise loue ses logiciels. Elle paie un abonnement mois après mois, ses données vivent chez un éditeur, et le jour où elle cesse de payer, tout s'éteint. Le logiciel est une dépense permanente qui ne lui appartient jamais.

Avec HORALIO, le modèle s'inverse. L'application tourne sur un serveur dédié au cabinet. Les données restent chez lui, sous son contrôle. Le logiciel n'est plus un service loué à l'extérieur, c'est un bien qu'il possède, un actif au même titre qu'un local ou une machine.

Deux choix techniques, décrits dans la version technique, rendent cette promesse tangible plutôt que rhétorique : l'application est figée dans un artefact autonome, reproductible et déplaçable d'un serveur à l'autre, et son déploiement s'appuie sur un outillage auto-hébergé plutôt que sur une plateforme tierce. Sans cela, la « propriété » resterait un vœu.

Des questions demeurent, légitimes : la maintenance dans le temps, l'évolution de l'outil, la dépendance à celui qui l'a construit. Elles sont réelles, et bien plus légères que le coût d'un logiciel équivalent fabriqué à l'ancienne.

Un changement d'échelle, pas une remise

Un mot sur le coût, sobrement, parce que la question vient toujours.

Faire réaliser de façon classique un logiciel équivalent, testé, documenté, livré avec son administration, reste un projet de plusieurs mois dont le budget se compte en centaines de milliers d'euros. Le détail du calcul figure dans la version technique, avec ses hypothèses et ses limites. HORALIO a été construit en seize jours, pour une fraction de ce montant.

L'écart n'est pas une remise commerciale, c'est un changement d'échelle. Quand le coût passe sous un certain seuil, ce qui était réservé aux grandes structures devient accessible aux petites, comme en leur temps l'imprimerie ou le site web.

(Ordres de grandeur, marché France, à ajuster selon la taille et le périmètre.)

Où est la vraie valeur, et ce qu'elle exige

Soyons lucides pour finir. L'intelligence artificielle a réellement multiplié la vitesse. Mais la valeur n'est pas dans la machine.

Beaucoup se trompent de combat. Distribuer des assistants conversationnels à tout le monde, demander à chacun de faire relire ses courriels avant de les envoyer : c'est sympathique, c'est limité, et c'est coûteux. De très grandes entreprises font aujourd'hui marche arrière devant l'envolée de ces dépenses. C'est l'illusion de la transformation, pas la transformation.

La transformation réelle demande un travail d'orfèvre : identifier précisément où, dans une organisation, se trouvent les points d'amélioration qui font gagner du temps, de la fiabilité, de la marge. Cette hauteur de vue, la machine ne l'apporte pas. Ce sont les femmes et les hommes du métier qui l'apportent. Encore un peu. Mais un peu, quand même.

Ce qui a fait tenir HORALIO, ce n'est pas la génération de code. C'est la méthode, et le jugement de savoir quand ne pas coder vite.

L'intelligence artificielle ne remplace pas l'expertise, l'expérience, la mémoire, l'intuition. Elle les amplifie de façon vertigineuse. Mais elle amplifie tout aussi vite les erreurs de celui qui n'en a pas.

Concrètement, comment cela se passe

Nous avons commencé par une question : qui utilise plus de la moitié des fonctions des logiciels qu'il paie ? Voici ce que nous faisons de cette question quand elle se pose chez vous.

Une demi-journée pour savoir s'il y a quelque chose à faire. On regarde ensemble vos fichiers parallèles, on identifie les doubles saisies, on écoute ce que vos équipes contournent au quotidien. À l'issue, soit un chantier utile apparaît et nous vous disons lequel, soit il n'y en a pas et nous vous le disons aussi. Cette demi-journée ne vous engage à rien.

Deux à trois semaines pour formaliser votre métier. C'est la phase décisive et la plus exigeante pour vous, parce qu'elle mobilise ceux qui savent. Nous mettons au clair vos objets, vos règles, l'ordre dans lequel elles s'appliquent, et ce que vous refusez de voir figurer dans l'outil. À la fin, vous détenez un document que vous pouvez lire, contester et corriger : le modèle de votre propre travail. Il vous appartient, même si vous décidez de vous arrêter là.

Quelques semaines pour livrer. Une première version en service, pas une maquette. Vos vraies données, vos vrais dossiers, vos vrais utilisateurs. Vous voyez en permanence ce qui est en cours, ce qui est planifié, ce qui a été écarté et pourquoi.

Et ensuite, la propriété. L'application tourne sur votre serveur. Vous en détenez le code et les données. Nous restons pour la faire évoluer si vous le souhaitez, mais vous n'êtes pas captif : c'est la différence entre posséder et louer.

Ce que nous ne faisons pas

Nous ne vendons pas de licence, il n'y a pas de catalogue. Nous ne paramétrons pas le produit d'un autre éditeur. Et nous ne prenons pas de mission dont nous ne serions pas capables de porter la mise en production, parce que celui qui conçoit doit être celui qui répond quand cela casse.

Envie du détail technique, la méthode, les tests, l'infrastructure ? Lire le retour d'expérience →