Du prototype à la production : pourquoi le logiciel d'entreprise exige toujours de l'ingénierie

Un directeur financier construit un outil de prévision de trésorerie en une fin de semaine, à l'aide d'un assistant IA, sans analyste financier ni développeur.

Une directrice des opérations dans une entreprise de distribution génère, à coups de prompts, une application de planification qui aurait exigé un contrat de six mois avec un fournisseur.

Un directeur marketing monte un outil de segmentation de clientèle en un après-midi, sans billet ouvert auprès des TI, sans développeur impliqué.

Rien de tout cela n'était possible il y a trois ans. Aujourd'hui, c'est monnaie courante, et rien de tout cela n'est réellement terminé.

Le prototype construit en une fin de semaine est devenu la norme

Un directeur financier construit un outil de prévision de trésorerie en une fin de semaine, à l'aide d'un assistant de programmation IA, sans analyste financier ni développeur.

Une directrice des opérations dans une entreprise de distribution génère, à coups de prompts, une application de planification qui aurait auparavant exigé un contrat de six mois avec un fournisseur.

Un directeur marketing monte un outil de segmentation de clientèle en un après-midi, sans billet ouvert auprès des TI, sans développeur impliqué.

Au lieu d'acheter des logiciels, les employés se mettent maintenant à les construire eux-mêmes.

Ce n'est pas un comportement marginal réservé aux équipes techniques. Ça se produit en finance, aux opérations, en vente et en marketing, dans des entreprises qui n'ont jamais eu d'équipe de développement interne.

Une démo qui fonctionne n'est pas un système en production

Le prototype fait exactement ce qu'on lui a demandé , une fois, pour un seul utilisateur, avec des données propres, sur un seul ordinateur portable.

Un système en production doit faire la même chose correctement pour des centaines d'utilisateurs, avec des données imparfaites, dans cinq ans, alors que la personne qui l'a construit aura probablement quitté l'entreprise.

Ce sont deux problèmes d'ingénierie complètement différents. L'IA a rendu le premier presque gratuit. Elle n'a pas fait disparaître le second.

La distance entre « ça fonctionnait pendant ma démo » et « ça fonctionne » , c'est là que se joue la majorité des projets de logiciels d'entreprise.

Où le risque se cache vraiment

Un prototype n'a presque jamais d'authentification. Il n'a presque jamais de copie de sauvegarde. Il tourne souvent sur un compte personnel, un ordinateur personnel, ou un service infonuagique gratuit dont personne aux TI ne connaît l'existence.

Rien de tout ça n'a d'importance tant que l'outil reste un projet parallèle. Ça devient critique le jour où quelqu'un le branche à de vraies données clients, à des données financières réelles, ou à un processus opérationnel actif.

Le risque, ce n'est pas que le prototype échoue. Un prototype qui échoue est sans conséquence , quelqu'un le remarque et recommence.

Le risque, c'est que le prototype fonctionne, devienne discrètement un pilier de l'organisation, et que personne n'y revienne jamais pour bien l'ingénierer.

Six éléments qui manquent systématiquement à un prototype bâti avec l'IA

L'écart entre un prototype et un système en production n'est pas cosmétique. C'est une liste précise et récurrente de travail d'ingénierie que les outils d'IA ne font pas d'eux-mêmes :

• L'authentification et la gestion des accès , qui a le droit de voir et de modifier quoi
• La validation des entrées et la gestion des erreurs , que se passe-t-il quand les données sont incomplètes, mal formées ou malveillantes
• La gouvernance des données et la traçabilité , où les données résident, qui peut y accéder, et comment les changements sont consignés
• Les tests de sécurité , l'outil peut-il être sondé, compromis, ou servir de porte d'entrée vers d'autres systèmes
• La performance sous charge réelle , que se passe-t-il avec 200 utilisateurs simultanés au lieu d'un seul
• Un propriétaire désigné et un plan de support , qui le répare à 2 h du matin quand il brise

Un prototype peut être brillant et tout de même passer à côté de ces six éléments.

Ce que ça coûte quand personne ne referme l'écart

La facture arrive rarement le premier jour. Elle arrive douze à dix-huit mois plus tard, une fois que le prototype est discrètement devenu un rouage du fonctionnement de l'entreprise.

À ce moment-là, le rebâtir correctement coûte plus cher que de l'avoir bien construit dès le départ , parce qu'il faut maintenant le refaire sans perturber le processus qui en dépend déjà.

Une fuite de données ou une panne causée par un outil non gouverné coûte largement plus cher que ce que l'outil a fait économiser en frais de consultation ou de licences. Les régulateurs, les clients et le conseil d'administration ne font pas de distinction entre « système officiel » et « prototype bâti avec l'IA » lorsqu'une brèche survient.

Et quand l'employé qui l'a construit quitte l'entreprise, la connaissance de son fonctionnement réel part généralement avec lui.

Prototype contre système de calibre production

Les deux se ressemblent souvent à l'œil nu. La différence se joue entièrement sous la surface.

Pourquoi l'IA a élargi l'écart plutôt que de le refermer

Parce que le prototypage est maintenant presque gratuit, le nombre de prototypes a explosé. Chaque service peut en produire un, et la plupart le font désormais.

Le goulot d'étranglement était autrefois « peut-on construire ça? ». Cette question est réglée. Le goulot d'étranglement est maintenant « qui va bien l'ingénierer, et quand? ».

La plupart des équipes TI et d'ingénierie ont été dimensionnées pour un monde où une poignée de projets leur arrivait chaque trimestre. Elles ne sont pas dimensionnées pour un monde où chaque service produit un logiciel fonctionnel chaque semaine.

L'IA n'a pas éliminé l'étape d'ingénierie. Elle a déplacé la pression vers elle.

De l'informatique fantôme à l'IA fantôme

L'informatique fantôme (« shadow IT ») désignait autrefois un abonnement infonuagique non autorisé sur un rapport de dépenses. C'était un problème d'approvisionnement.

L'IA fantôme, c'est différent. Ça signifie qu'un processus d'affaires actif , tarification, planification, prévisions, communication client , tourne sur un outil que personne aux TI n'a révisé, sécurisé, testé ou sauvegardé.

Ce n'est plus un problème d'approvisionnement. C'est une exposition opérationnelle et sécuritaire logée à l'intérieur même de l'entreprise, touchant souvent les mêmes données clients et financières que le reste de l'organisation s'efforce de protéger.

La plupart des équipes de direction peuvent nommer leurs dépenses en logiciels infonuagiques. Très peu peuvent nommer chaque outil bâti avec l'IA qui fait actuellement tourner un vrai processus dans leur entreprise.

La dette de prototype est la nouvelle dette technique

La dette technique s'accumulait autrefois lentement, un raccourci à la fois, à l'intérieur de systèmes déjà connus des TI.

La dette de prototype s'accumule autrement. Elle apparaît toute formée, hors du champ de vision des TI, dès qu'une séance de prompts réussie se termine.

Chaque prototype qui devient discrètement un pilier de l'organisation est un passif que l'entreprise porte sans le savoir , aucune ligne au bilan, aucun billet dans un carnet de projets, aucun responsable qui en répond.

Plus les prototypes se construisent rapidement, plus ce passif s'accumule vite, à moins qu'un mécanisme actif ne les convertisse en systèmes bien ingénierés.

À quoi ressemble une bonne gouvernance

Ici, gouvernance ne veut pas dire ralentir le prototypage. Le prototypage doit rester rapide , cette vitesse est un véritable avantage.

Ça veut dire insérer un point de contrôle délibéré entre « ça fonctionne comme démo » et « ça fait maintenant tourner un processus d'affaires ». Avant qu'un outil bâti avec l'IA touche à de vraies données clients ou s'intègre à un processus actif, il devrait passer par :

• Une étape d'inventaire , quelqu'un aux TI sait que l'outil existe
• Une classification du risque , quelles données il touche et ce qui se passe s'il échoue
• Une révision d'ingénierie , sécurité, gestion des erreurs et évolutivité évaluées selon l'usage réel prévu
• Un propriétaire désigné , une personne ou une équipe responsable de l'outil une fois en service
• Un budget de maintenance , du temps et des ressources alloués pour le garder en fonction, pas seulement pour le construire

Rien de tout ça n'exige d'empêcher les employés de construire des outils. Ça exige de décider, délibérément, quels prototypes méritent de passer à l'étape suivante , et de bien les ingénierer quand c'est le cas.

Ce que les dirigeants devraient mesurer

La plupart des équipes de direction suivent les dépenses infonuagiques et les échéanciers de projets. Très peu suivent les indicateurs qui révèlent réellement ce risque.

• Le nombre d'outils bâtis avec l'IA qui font actuellement tourner un processus d'affaires sans révision des TI
• Le pourcentage de processus critiques dépendant de logiciels sans propriétaire désigné
• Le délai moyen entre « prototype fonctionnel » et « système ingénieré et soutenu »
• Le nombre d'incidents , pannes, problèmes de données, failles de sécurité , attribuables à des outils non gouvernés

Aucun de ces chiffres n'apparaît dans un tableau de bord TI standard. Il faut les demander expressément.

La discipline d'ingénierie devient le prochain avantage concurrentiel

N'importe quel concurrent peut maintenant prototyper rapidement. Ce n'est plus un facteur de différenciation , c'est devenu le minimum attendu.

L'avantage se déplace vers les organisations capables de transformer, de façon fiable et répétée, un bon prototype en système sécurisé, évolutif et facile à maintenir , sans perdre la vitesse qui a rendu ce prototype possible en premier lieu.

Ce n'est pas un problème d'outillage. C'est une discipline d'ingénierie et de gouvernance, et c'est là que se jouera la prochaine vague d'avantage technologique en entreprise.

Les entreprises qui traitent le prototypage IA comme une ligne d'arrivée en paieront tranquillement le prix au cours des prochaines années. Celles qui le traitent comme une ligne de départ seront celles qui seront encore debout.