Développement sur-mesure : ce que le marché ne vend pas déjà

Trois situations le justifient, et elles seules : quand l’agent doit atteindre vos données internes, quand la tâche traverse plusieurs outils, et quand vous avez des garanties de conformité qu’un outil grand public ne donne pas.

Sur ce dernier point, voici ce que peu de prestataires disent : les États-Unis ne figurent pas dans les trente-deux pays de la délibération CNDP n° 236-2015. Confier des données personnelles à un fournisseur américain impose donc au responsable du traitement le formulaire F118 et deux mois d’instruction, prorogeables une fois — sur le chemin critique du projet. Un fournisseur européen supprime cette demande.

Dans tous les autres cas, nous vous recommandons l’outil du marché. Il est presque toujours plus rapide à mettre en place, et moins cher à tenir.

Quatre causes reviennent : viser l’agent entièrement autonome dès le premier jour, des données trop sales pour être exploitées, un outil que personne n’adopte, et un entretien qu’on n’avait pas budgété.

La méthode ci-dessus est faite contre ces quatre-là : un prototype obligatoire, des étapes courtes, et deux revues où vous pouvez arrêter.

Sur la première cause — viser l’agent entièrement autonome — deux bancs d’essai universitaires donnent la mesure : le meilleur agent testé mène 30 % des tâches de bureau au bout tout seul, et 14 % des tâches web contre 78 % pour un humain — ce qu’un agent autonome sait faire, et ce qu’il rate.

Sur la deuxième cause — des données trop sales — un écrit du journal détaille ce que la recherche mesure : enrichir les métadonnées d’un RAG d’entreprise, d’après une étude de décembre 2025.

Un agent qui demande une validation humaine avant toute action qui engage : envoyer, payer, signer, supprimer.

Il peut aussi porter un seuil : en dessous d’un certain niveau de certitude, il s’arrête et vous passe la main plutôt que de trancher seul.

Ce seuil se règle et se vérifie ; il ne s’obtient pas par défaut. Des mesures publiées montrent qu’un modèle branché sur vos documents s’abstient moins souvent qu’un modèle qui n’en a aucun — ce qu’un RAG rate en production.

Ceux du marché tant qu’ils suffisent — les plateformes d’automatisation sans code, et les modèles accessibles par abonnement.

Le choix dépend de vos intégrations et de vos contraintes, jamais d’un partenariat : nous n’en avons aucun, et nous ne touchons de commission sur rien.

Parce qu’il répond en deux semaines à trois questions qu’aucune réunion ne tranche : est-ce faisable, la qualité est-elle au rendez-vous, et vos équipes s’en servent-elles.

Il est obligatoire sur tout projet d’agent. Un obstacle trouvé au prototype coûte une semaine ; trouvé après le développement, il coûte le projet.

L’outil vous appartient, avec son code et sa documentation. Vous pouvez le faire tenir par qui vous voulez.

Si vous nous confiez l’entretien, il couvre le support, la surveillance des performances, les réglages et les mises à jour rendues nécessaires par les fournisseurs.

Les accès sont limités à ce dont l’agent a besoin, et chaque action qu’il exécute est journalisée.

Aucun de vos documents n’est envoyé à un fournisseur de modèle pour l’entraîner. L’hébergement des traitements se décide au cadrage, et il est écrit au contrat.

Non. Un agent qui décide seul de ce qui engage l’entreprise est un agent que personne ne surveille — et le jour où il se trompe, c’est vous qui répondez, pas lui.

Nous ne livrons que des agents encadrés : ils font le travail, vous gardez la main sur ce qui engage.

L’ordre dans lequel nous proposons les choses. D’abord l’outil du marché, ensuite l’automatisation sans code, et le développement en dernier — seulement quand rien d’autre ne fait le travail.

Un cabinet payé au développement n’a aucune raison de vous dire que l’abonnement à 20 euros suffisait.

Oui, si vous avez déjà identifié la tâche et vérifié qu’aucun logiciel du marché ne la fait. C’est le seul cas où c’est raisonnable.

Dans le doute, l’audit des cas d’usage coûte moins cher qu’un développement qui vise à côté. Et une fois l’outil livré, ce qui décide de son usage réel est la conduite du changement.

Oui, et c’est l’un des quatre paliers de cette page. Mais pas un site vitrine de plus : un site construit pour être exploré par les moteurs, compris par les assistants IA, et relié à ce que vous avez déjà — votre catalogue, votre agenda, votre outil de gestion.

Un site qu’on ne trouve pas n’a aucune valeur. C’est pourquoi la construction et la visibilité et acquisition se mènent ensemble, et pourquoi l’audit de visibilité dit souvent qu’il ne faut pas refaire le site — mais le rendre lisible.

C’est le palier le plus long — deux à quatre mois — et le seul que nous ne prenons jamais sans audit préalable. Une application qui rate son besoin coûte deux fois : à la construction, puis à chaque mois où personne ne l’ouvre.

Elle tourne sur votre propre instance, et personne ne partage une machine avec un autre client. Ce que vous payez au mois ensuite, c’est l’exploitation — pas une licence qui vous enferme.

Faites-le, si c’est une vitrine que personne ne cherchera. Nous le dirons nous-mêmes : développer ce qui existe déjà se paie deux fois, et c’est ce que l’audit est payé pour établir.

Le sur-mesure ne se justifie que quand le site doit faire quelque chose — se brancher à vos données, tenir un volume, ou être trouvé sur un terrain que quelqu’un d’autre occupe déjà. Sinon, un modèle du marché suffit, et nous vous le dirons.