Comment nous décidons qu'un produit ne mérite pas d'exister.
Nous éditons des produits numériques professionnels. La question qu'on nous pose — et que nous nous sommes posée en premier — est simple : pourquoi acheter un kit quand on peut demander à une IA ? Notre réponse tient moins dans ce que nous produisons que dans ce que nous refusons de produire. Cas interne : notre propre catalogue, pas une mission client.
Le problème
Un catalogue de fichiers devient interchangeable.
Un guide générique perd sa valeur en une requête. Produire vite crée des doublons, des promesses vagues et des fichiers incomplets. Et sans gouvernance, les sources se périment : un produit qui fonctionne six mois puis ment. Nous avons audité notre propre gamme et tranché : ne plus construire un catalogue de fichiers, mais un système de produits vivants — qui partagent une architecture commune de preuve, de décision, de donnée et de mise à jour.
Notre doctrine
Ce qu'une requête IA ne produit pas.
Nous avons formalisé des critères de valeur. Un produit ne mérite d'exister que s'il apporte ce qu'une génération de texte ne fournit pas. Il ne s'agit pas d'opposer produit et IA — nous utilisons l'IA nous-mêmes, et cette page ne prétend pas le contraire — mais de concevoir ce qu'elle ne couvre pas.
- Des données structurées — pas de la prose : des grilles, des matrices, des référentiels renseignés.
- Des calculs déterministes — des règles, des seuils, des scores qui produisent un résultat testable, séparés de toute sortie générative.
- Des preuves — sources datées, propriétaire, périmètre, validité.
- Des contrôles — des vérifications intégrées, et une validation humaine avec des rôles et des exceptions.
- De la maintenance — le produit suit la réglementation et la pratique. Une requête, non.
La méthode
Des points de passage, avant la première ligne de code.
Chaque produit franchit une série de contrôles avant d'être construit — la qualité et l'économie passent avant le développement. Quelques-uns, parmi les plus discriminants :
- Le problème est-il critique ? Des entretiens convergents et un coût de l'inaction, sinon on arrête.
- Y a-t-il un acheteur et un budget ? Un utilisateur enthousiaste sans sponsor ne suffit pas.
- Le produit conduit-il à un arbitrage ? S'il ne produit qu'un contenu ou une checklist, il ne mérite pas d'exister.
- Résiste-t-il à l'IA ? Un écart mesuré face à une réponse générique. En dessous du seuil, on retravaille ou on abandonne.
- Réemploie-t-il l'existant ? Une création isolée est refusée : le produit doit s'appuyer sur des composants déjà éprouvés.
- La maintenance est-elle financée ? Sources, propriétaire, cadence, engagement de service. Une promesse vague de mise à jour est un motif d'arrêt.
- Deux pilotes payants existent-ils ? Un intérêt verbal n'est pas une preuve de marché.
- Quand l'arrête-t-on ? Chaque produit a une date et un critère d'arrêt acceptés d'avance.
Livrables : critères de valeur, architecture de packaging, structure de produit (ZIP avec README, outil, guide d'usage et rapport exemple), checklist qualité, politique de maintenance (veille, versionnage, criticité, cycles, retrait) et changelog.
Ce que ça prouve
La capacité est transférable.
Vous n'éditez probablement pas de catalogue numérique. Mais la question est la vôtre : qu'est-ce qui, dans votre offre, résiste à l'automatisation — et qu'est-ce qui ne le mérite pas ? Nous appliquons à notre propre gamme la méthode que nous proposons dans le Studio de solutions métier : arbitrer, structurer, contrôler, maintenir, et savoir arrêter. C'est le même travail.
Périmètre et honnêteté
Ce que ce cas est — et n'est pas
Ce cas décrit notre propre catalogue, pas une mission client — nous le disons plutôt que de le déguiser. Il ne contient ni chiffre de vente, ni prix, ni projection, ni roadmap détaillée. Le canal de distribution est en cours de construction : nous ne le présentons pas comme opérationnel tant qu'il ne l'est pas.
Une offre à protéger de l'automatisation ?
La question se cadre en un échange court : ce qui, chez vous, résiste — et ce qui ne le mérite pas.