Pendant longtemps, la technologie était un vrai différenciant.

Celui qui pouvait s'offrir une grosse base Oracle, de gros serveurs, une infra sérieuse et les équipes pour faire tourner tout ça avait un avantage concurrentiel réel. Le ticket d'entrée était élevé. La technologie elle-même faisait une partie du moat.

Puis le cloud est arrivé.

Avec AWS, Google Cloud, Azure et les autres, les mêmes briques technologiques sont devenues accessibles à tout le monde. On n'a plus besoin d'acheter lourdement en amont : on peut louer à l'usage. On n'a plus besoin d'être déjà gros pour s'équiper comme un gros.

Résultat : la technologie s'est largement banalisée.

Bien sûr, il y a encore des écarts d'exécution. Certains construisent mieux que d'autres. Certains opèrent mieux, sécurisent mieux, architecturent mieux. Mais le simple fait d'avoir "la technologie" n'est plus, à lui seul, un différenciant durable.

Et avec l'IA, on va franchir une étape supplémentaire.

On va pouvoir produire plus vite :

• plus de fonctionnalités,
• plus d'écrans,
• plus de variantes,
• plus de contenus,
• plus de code.

Le coût de production du logiciel va continuer à baisser. Et donc le nombre d'acteurs capables d'attaquer un marché va continuer à monter.

Mais si tout le monde peut produire vite et bien, alors produire vite et bien ne suffit plus.

Sortir des features au kilomètre ne sera plus un avantage. Ce sera juste le niveau de base.

C'est pour ça que je suis de plus en plus convaincu que, pour les éditeurs de logiciels, le vrai différenciant va se déplacer ailleurs : vers la compréhension du contexte.

Ce qui va compter, c'est comprendre avant de construire

Quand la technologie se commoditise, et quand la capacité de production devient abondante, la rareté change de place.

Elle n'est plus dans le "faire". Elle est dans le "comprendre".

Comprendre le contexte, ce n'est pas juste écouter deux clients, faire trois interviews et écrire une note de cadrage. C'est comprendre en profondeur tout ce qui encadre une opportunité produit.

Par exemple :

• le métier,
• les utilisateurs,
• les clients,
• les contraintes techniques,
• les normes,
• la culture terrain,
• la concurrence.

Dit autrement : les meilleurs éditeurs ne gagneront pas parce qu'ils produisent plus. Ils gagneront parce qu'ils comprennent mieux.

Comprendre le business, vraiment

Beaucoup d'équipes logicielles construisent encore des fonctionnalités sans comprendre :

• le modèle économique du client,
• ses arbitrages,
• ses marges,
• ses contraintes opérationnelles,
• ses priorités réelles,
• et sa culture.

Et cette dimension culturelle est loin d'être secondaire. Elle est souvent décisive, en particulier dans :

• les grands groupes,
• les entreprises internationales,
• certaines verticales très codifiées.

Deux entreprises peuvent avoir le même besoin apparent sur le papier et attendre en réalité deux choses très différentes, simplement parce qu'elles n'ont pas :

• la même culture de décision,
• le même rapport au risque,
• le même niveau de centralisation,
• le même rapport au siège et au terrain,
• la même attente de standardisation.

Quand on ne comprend pas ça, on peut construire quelque chose de correct… mais à côté.

Dans un monde où tout le monde pourra construire, la vraie question ne sera plus : "est-ce qu'on peut développer cette feature ?" mais plutôt : "est-ce qu'on comprend assez bien la situation pour construire la bonne chose ?"

Comprendre les utilisateurs, pas les utilisateurs imaginaires

Il y a souvent un monde entre l'utilisateur qu'on imagine dans un workshop et celui qui travaille réellement sur le terrain.

Ce qu'il faut comprendre, ce sont :

• ses contraintes,
• ses habitudes,
• ses raccourcis,
• ses résistances,
• sa charge mentale,
• ses contournements.

Avec l'IA, on pourra générer des interfaces très vite. Mais générer vite une mauvaise réponse à un vrai problème reste… une mauvaise réponse.

La différence se fera donc sur la qualité de compréhension :

• est-ce qu'on sait comment les gens travaillent vraiment ?
• est-ce qu'on comprend ce qu'ils tolèrent, ce qu'ils rejettent, ce qu'ils n'osent pas dire ?
• est-ce qu'on saisit les différences selon les rôles, les secteurs, la maturité digitale, ou la taille de l'entreprise ?

Comprendre le client, pas seulement l'utilisateur

En B2B, le client n'est pas juste "l'utilisateur".

Le client, c'est souvent aussi :

• celui qui paie,
• celui qui arbitre,
• celui qui porte le projet,
• celui qui doit rassurer sa hiérarchie,
• celui qui a peur du risque,
• celui qui se demande si le déploiement sera tenable.

Un produit peut :

• être apprécié par les utilisateurs et pourtant ne pas se vendre,
• résoudre un vrai problème et quand même se faire bloquer au moment de l'achat,
• être bon, mais incompatible avec les critères de décision de l'organisation.

Là encore, la compréhension du contexte devient centrale.

Comprendre la technique, mais autrement

Dire que la technologie n'est plus le différenciant principal ne veut pas dire qu'elle ne compte plus.

Elle compte toujours, mais différemment.

Ce qui va faire la différence, ce n'est pas juste d'avoir accès à la bonne stack. C'est de comprendre ce qu'il est raisonnable, robuste et soutenable de construire dans un contexte donné.

Avec l'IA, on pourra produire plus de code. Mais on n'aura pas automatiquement :

• plus de cohérence d'architecture,
• plus de fiabilité,
• plus de sécurité,
• ni de meilleures intégrations.

La question devient donc moins "peut-on coder ça ?" que :

• peut-on l'intégrer proprement ?
• peut-on le maintenir ?
• peut-on le sécuriser ?
• peut-on le faire tenir dans le réel ?

Comprendre la concurrence, les signaux faibles, les angles morts

L'autre piège, c'est de penser son produit en vase clos.

Le marché bouge pendant qu'on construit. Les concurrents changent, les attentes se déplacent, des usages deviennent standards, d'autres disparaissent, de nouveaux entrants arrivent plus vite qu'avant.

Avec l'IA, cette pression va encore augmenter. Il y aura plus d'acteurs capables de lancer quelque chose de crédible.

Donc il faudra comprendre :

• ce que font les concurrents,
• ce qu'ils promettent,
• ce qu'ils ne savent pas faire,
• où le marché se standardise,
• où il reste encore de vrais angles morts.

Normes, réglementation, traçabilité : un sujet de plus en plus central

Je pense aussi qu'on sous-estime encore à quel point le contexte réglementaire et normatif va prendre de la valeur dans les années qui viennent.

On pense souvent à :

• les normes ISO,
• les référentiels métiers,
• les exigences d'audit,
• la cybersécurité,
• la protection des données,
• la conformité sectorielle.

Mais il y a aussi toute une couche très concrète, très terrain, qui prend de plus en plus d'importance :

• la traçabilité,
• l'archivage,
• la normalisation,
• la comparabilité des données,
• la justification des écarts,
• la lisibilité pour la finance ou le contrôle.

Très souvent, ça se traduit par des phrases toutes simples :

• "le contrôleur de gestion me demande ça",
• "il faut qu'on puisse justifier ce chiffre",
• "il faut retrouver qui a fait quoi, quand, et pourquoi",
• "il faut que ce soit comparable entre sites",
• "il faut une donnée exploitable pour l'audit".

Autrement dit, il ne s'agit plus seulement de construire un outil utile. Il faut aussi construire un outil qui :

• laisse des traces,
• structure l'information,
• rende les décisions lisibles,
• tienne face à une logique d'audit,
• tienne face à une logique de pilotage,
• tienne face à une logique de standardisation.

Et ça, ce n'est pas juste de la technique. C'est de la compréhension fine du contexte client.

Ce qui va prendre de la valeur : le document de contexte

Concrètement, je pense qu'un des livrables qui va prendre le plus de valeur dans les années à venir, ce n'est pas seulement la spec, ni même la roadmap.

Ce sera un vrai document de contexte pour une opportunité donnée.

Un document qui force à expliciter, noir sur blanc :

• le contexte business,
• le contexte produit,
• le contexte client,
• le contexte utilisateur,
• le contexte technique,
• les règles métier,
• les normes et la réglementation,
• la culture et les pratiques terrain,
• la concurrence et les alternatives,
• l'historique et les décisions déjà prises.

Et un bon document de contexte ne sert pas seulement à empiler des faits. Il sert aussi à distinguer :

• ce que je sais,
• ce que je crois,
• ce qui me fait douter,
• ce qu'on ne dit pas.

Parce que demain, quand produire sera plus facile pour tout le monde, ce qui aura de la valeur ne sera pas juste la capacité à sortir une solution.

Ce sera la capacité à :

• cadrer correctement le problème,
• documenter le contexte,
• rendre visibles les zones de risque,
• aligner l'équipe sur une compréhension plus profonde de l'opportunité.

En fait, ce document de contexte devient presque un actif stratégique.

Au fond, l'avantage concurrentiel se déplace

Je crois qu'on entre dans une période où l'avantage concurrentiel des éditeurs de logiciels va se déplacer très nettement.

Hier, il était beaucoup dans l'accès à la technologie. Aujourd'hui, il est déjà moins là. Demain, avec l'IA, il sera encore moins dans la production elle-même.

Le vrai avantage sera dans la qualité de compréhension.

Comprendre mieux que les autres :

• le métier,
• les utilisateurs,
• les clients,
• les contraintes techniques,
• les normes,
• la culture terrain,
• la concurrence,
• et tous les signaux faibles qui changent la nature d'une opportunité.

Quand tout le monde peut construire, celui qui gagne n'est pas celui qui produit le plus.

C'est celui qui comprend le mieux quoi construire, pour qui, dans quel environnement, avec quelles contraintes, et pour créer quelle valeur.

Exemple concret

• 00-context.md

**Statut** : Draft / In review / Validated
**Owner** : PM
**Dernière mise à jour** : YYYY-MM-DD

# Context

## Contexte business
_Quels sont les enjeux business derrière ce sujet ? Pourquoi il existe ? Quelles contraintes business connues ? Est-ce que cette opportunité fonctionne pour notre modèle économique, notre go-to-market, notre stratégie ?_
_(→ risque de viabilité business)_



## Contexte produit
_Comment ça marche aujourd'hui ? Quelles sont les limites actuelles ? Qu'est-ce qui a déjà été tenté ou envisagé ?_



## Contexte client
_Qui est le client (celui qui paie, qui décide l'achat) ? Quels sont ses enjeux, ses critères de décision, ses contraintes ? Qu'est-ce qui motive ou bloque l'achat ? Ce sujet répond-il à un besoin que le client est prêt à payer ?_
_(→ risque de valeur côté acheteur)_



## Contexte utilisateur
_Qui utilise le produit au quotidien ? Quels usages aujourd'hui ? Quels pain points connus ? L'utilisateur va-t-il comprendre et adopter la solution ? Des différences selon les segments ou les rôles ?_
_(→ risque de valeur + risque d'utilisabilité)_



## Contexte technique
_Éléments techniques utiles à connaître ? Peut-on construire ce qu'on envisage avec nos compétences, notre stack et nos délais ? Contraintes data ou tracking ? Dépendances importantes ?_
_(→ risque de faisabilité)_



## Règles métier
_Quelles règles métier existent déjà dans notre CMMS sur ce sujet ? Comment nos clients gèrent ça aujourd'hui dans leurs process ? Logiques de validation, de calcul, de droits, de workflow déjà en place ?_



## Normes et réglementation
_Quelles normes (ISO, EN, NF…) ou obligations réglementaires s'appliquent ? Quels impacts sur ce qu'on peut ou doit construire ? Des exigences de traçabilité, de conformité, d'audit ?_



## Culture et pratiques terrain
_Comment les équipes terrain travaillent réellement ? Quelles habitudes selon le secteur (industrie, tertiaire, santé…) ou la taille d'entreprise ? Quelles perceptions, résistances ou attentes spécifiques à prendre en compte ?_



## Concurrence et alternatives actuelles
_Comment les clients résolvent ce problème aujourd'hui ? Quel concurrent, quel outil maison, quel process manuel (Excel, papier…) ? Qu'est-ce qui marche ou ne marche pas dans ces alternatives ?_



## Historique et décisions
_Décisions déjà prises sur ce sujet ? Arbitrages historiques utiles ? Éléments à ne pas rouvrir sans raison ?_