Prototypes logiciels et études de faisabilité avec l’IA

Le regard immédiat sur le codage par IA tient en une phrase : les projets logiciels existants vont plus vite. C'est exact, mais cela ne décrit qu'une part du changement.

Plus important stratégiquement : l'ensemble des idées économiquement explorables s'agrandit.

Une nouvelle application n'a plus à être décrite pendant des mois uniquement comme un concept. Un système métier spécialisé, un environnement de simulation, un système de planification visuel ou une nouvelle idée de produit numérique peut prendre forme bien plus tôt comme logiciel cohérent.

Il ne s'agit donc pas simplement de traiter plus vite le portefeuille de projets existant. Des idées entrent en développement qui, auparavant, n'auraient pas franchi le seuil économique d'un projet informatique classique.

Le changement pertinent ne tient donc pas seulement à la productivité. Il tient à un espace de recherche entrepreneurial plus vaste.

Les modèles de développement classiques obligent les entreprises à sélectionner tôt. Seules quelques idées reçoivent un budget. Ces idées sont ensuite poursuivies assez loin, parce que des ressources considérables sont déjà engagées.

Lorsque le coût d'un développement technique précoce baisse, cet ordre peut être en partie inversé. Davantage d'idées de produit peuvent d'abord être portées à un niveau technique réel. Ce n'est qu'ensuite qu'il faut décider quelles approches justifient d'autres investissements.

Le développement de produit passe ainsi d'une logique de décision précoce à une logique de connaissance précoce.

Cela ne veut pas dire produire le plus d'expériences possible. Ce qui compte, c'est bien plutôt de réduire l'incertitude là où elle influence réellement les décisions d'entreprise.

Éprouver davantage. Apprendre plus tôt. Écarter plus tôt les approches faibles. Développer plus sûrement les approches fortes.

Le développement logiciel est traditionnellement compris comme l'exécution d'une décision déjà prise. On définit d'abord ce qui doit voir le jour. Ensuite, on développe.

Pour les produits nouveaux, cette séparation n'a qu'un sens limité. Une part des enseignements décisifs ne naît qu'au cours du développement.

Seule une véritable interface montre si une idée d'interaction tient. Seules de vraies données rendent visible si un modèle de données convient. Seul un noyau de système qui fonctionne montre si architecture, performance et logique produit s'accordent. Seul un système utilisable permet d'estimer de façon réaliste ce qu'une idée de produit peut réellement devenir.

Le développement ne produit donc pas seulement du logiciel. Il produit de l'information sur le produit à venir.

Dans une phase produit précoce, un état de développement solide peut produire plus de connaissance qu'un tour de spécification abstraite supplémentaire.

Le caractère expérimental de cette approche ne signifie pas qu'il n'en sort que des logiciels petits ou provisoires.

Ce qui est expérimental, c'est l'ouverture du processus de connaissance.

Une application de bureau techniquement exigeante peut elle aussi être développée de façon expérimentale, si son but est d'abord d'éprouver réellement une idée de produit et d'en affûter la direction au fil du développement.

Un état de développement précoce peut déjà comporter plusieurs éléments liés : une véritable interface, une logique métier, une gestion des données, de la visualisation, de la persistance, des fonctions d'import et d'export, une communication avec des systèmes externes ou un noyau technique solide.

Le travail va ainsi nettement au-delà d'un prototype cliquable purement visuel.

Le but est d'obtenir le plus de réalité produit solide possible dans le temps de développement le plus court possible.