Pendant la majeure partie de son histoire, le logiciel a été apprécié pour ce qu’il faisait : la logique qu’il encodait, les workflows qu’il automatisait, les écrans qu’il organisait. À l’ère de l’IA, ce centre de gravité se déplace. Lorsqu’un modèle peut écrire la logique et générer l’écran à la demande, ce qui reste rare, ce sont les données sous-jacentes, et le savoir-faire nécessaire pour les présenter de façon à ce que chacun puisse les comprendre et agir en conséquence.

Cet essai soutient que le logiciel et l’expérience utilisateur deviennent, de plus en plus, la couche de présentation des données. Le code se banalise, les interfaces deviennent fluides, et les données deviennent l’actif qui désigne les gagnants. Pour comprendre pourquoi, il est utile de commencer par le début.

Une brève histoire du logiciel

Les premiers programmes n’étaient pas du tout des produits. Dans les années 1940 et 1950, le logiciel était un ensemble d’instructions câblées ou perforées dans une machine donnée pour effectuer un calcul donné : tables de tir d’artillerie, dépouillements de recensement, paie. Le matériel était la partie coûteuse et prestigieuse. Le code était secondaire, souvent fourni gratuitement avec la machine.

Cela a changé dans les années 1960 et 1970. La décision d’IBM, en 1969, de facturer le logiciel séparément du matériel a contribué à créer une industrie du logiciel. Des langages de haut niveau comme FORTRAN, COBOL et C ont permis aux programmeurs de décrire une intention plutôt qu’un câblage, et la base de données relationnelle, proposée par Edgar Codd en 1970, a donné aux entreprises une méthode rigoureuse pour stocker et interroger leurs enregistrements. Très tôt, le logiciel le plus précieux a été celui qui gérait des données.

L’ordinateur personnel de la fin des années 1970 et des années 1980 a mis le logiciel entre les mains du grand public. VisiCalc, le premier tableur, a été la raison pour laquelle de nombreuses entreprises ont acheté un Apple II. Le traitement de texte et la publication assistée par ordinateur ont suivi. Le logiciel est devenu quelque chose que l’on achetait en boîte, que l’on installait et que l’on possédait.

Internet a ensuite fait disparaître la boîte. Au cours des années 1990 et 2000, le logiciel est passé au navigateur, puis au cloud. Salesforce a fait de « no software » son slogan en 1999, et le logiciel en tant que service (SaaS) a transformé les programmes en abonnements. À partir de 2007, le smartphone a fragmenté le logiciel en millions de petites applications, chacune offrant une fenêtre ciblée sur un service particulier. Dans les années 2010, « le logiciel dévore le monde » était devenu la devise du secteur, et presque toutes les entreprises étaient devenues, en partie, des entreprises de logiciel.

L’ère de l’interface : quand l’UX est devenue le produit

À mesure que le logiciel se diffusait auprès de non-spécialistes, l’interface est devenue le terrain d’affrontement. L’interface graphique du Xerox PARC, popularisée par le Macintosh en 1984, a remplacé les commandes apprises par cœur par des fenêtres, des icônes et une souris. Elle a montré que la même capacité, mieux présentée, pouvait toucher un public plus large de plusieurs ordres de grandeur.

Dans les années 2010, l’expérience utilisateur était devenue une discipline à part entière. Les entreprises recrutaient des équipes de design, menaient des tests A/B et construisaient des design systems. Sur des marchés encombrés, des produits aux fonctionnalités presque identiques rivalisaient sur leurs parcours d’intégration, leur finition visuelle et le peu de gestes nécessaires pour mener une tâche à bien. Pour beaucoup de produits, l’UX était devenue le produit lui-même.

Pourtant, même à cette époque, il suffit de regarder de près ce que faisaient la plupart de ces interfaces. Une application bancaire affiche des soldes et des transactions. Un CRM affiche des contacts et des affaires. Une application de VTC affiche des voitures sur une carte. Sous la finition, presque chaque écran était une vue soigneusement conçue d’enregistrements dans une base de données, assortie de quelques boutons pour les modifier. Le secteur se décrivait rarement ainsi, mais le schéma était déjà là.

Le tournant de l’IA : quand la logique devient bon marché, les données deviennent le rempart

Les grands modèles de langage changent l’économie du logiciel à la racine. Écrire du code, autrefois le goulet d’étranglement de chaque projet, devient rapide et peu coûteux. Un modèle compétent peut poser l’ossature d’une application, écrire les tests et générer un tableau de bord en quelques minutes. Lorsqu’une chose devient bon marché à produire, elle cesse d’être un avantage durable.

Ce qui ne peut pas être généré à la demande, ce sont les données. Un modèle peut écrire un écran d’inventaire parfait, mais il ne peut pas inventer les niveaux de stock réels d’un distributeur, dix ans d’historique client, ou le signal discret que révèle le comportement réel des utilisateurs. Des données propriétaires, bien structurées et fiables sont désormais ce que les concurrents ne peuvent pas copier à coups de prompts.

Les données comptent aussi davantage parce que l’IA les consomme. Les modèles sont entraînés sur des données, ancrés dans celles-ci par la récupération d’informations, et évalués par rapport à elles. Une fonctionnalité d’IA ne vaut que par le contexte qu’on lui fournit. Une entreprise disposant de données propres, connectées et encadrées par des droits d’accès peut construire une IA utile en quelques semaines ; une entreprise aux données dispersées et incohérentes ne le peut pas, quelle que soit la puissance de son modèle. La qualité de la couche de données fixe de plus en plus le plafond de la qualité du produit tout entier.

Une UX réinventée : des interfaces comme vues sur les données et l’intention

Si les données sont la substance, l’interface devient leur présentation, et cette présentation n’a plus besoin d’être figée. Le logiciel traditionnel livrait les mêmes écrans à tout le monde, conçus des mois à l’avance. L’IA permet de générer la vue adaptée à la question : un graphique lorsque vous vous interrogez sur une tendance, un tableau lorsque vous devez comparer, un bref résumé lorsque vous êtes pressé, un e-mail rédigé lorsque l’étape suivante est évidente.

Le travail du designer passe ainsi du dessin d’écrans à la conception de systèmes. Les questions deviennent : de quelles données l’utilisateur a-t-il besoin pour faire confiance à cette réponse ? Comment montrer d’où vient un chiffre ? Quand le système doit-il agir seul, et quand doit-il demander ? Comment rendre l’incertitude visible sans submerger les gens ? Une bonne UX d’IA repose davantage sur la provenance, le niveau de confiance et le contrôle que sur la mise en page au pixel près.

La conversation en fait partie, mais seulement en partie. Le chat est un moyen puissant d’exprimer une intention, mais un piètre moyen de parcourir mille lignes ou de comparer cinq options côte à côte. Les interfaces gagnantes combineront probablement les deux : le langage naturel pour demander, et des vues visuelles générées et conçues sur mesure pour répondre. Dans les deux cas, l’interface est un prisme sur les données, et sa qualité se mesure à la clarté avec laquelle elle permet de voir et d’agir.

Ce que cela signifie pour le secteur

La première conséquence est une pression sur les logiciels à faible valeur ajoutée. Les produits dont la valeur principale était une interface plus agréable posée sur les données de quelqu’un d’autre, ou un workflow qu’un modèle peut désormais exécuter directement, verront leurs marges comprimées. Si un utilisateur peut demander à un assistant d’extraire les chiffres et de rédiger le rapport, un outil de reporting autonome doit offrir quelque chose de plus.

La deuxième conséquence est que les systèmes de référence prennent de la valeur. Les entreprises qui détiennent des données fiables et structurées sur les clients, les transactions, les opérations ou le monde physique occupent le socle dont dépend chaque couche d’IA. Il faut s’attendre à davantage de concurrence pour le contrôle de ces données, à une attention accrue portée à l’interopérabilité et aux API, et à des débats plus vifs sur la confidentialité, le consentement et la propriété.

La troisième conséquence est que la confiance devient une fonctionnalité. À mesure que l’IA génère une part croissante de ce que les gens voient, les utilisateurs se demanderont comment savoir qu’une réponse est juste. Les produits qui montrent leurs sources, maintiennent leurs données à jour, respectent les droits d’accès et expliquent leur raisonnement susciteront une adoption que des concurrents plus séduisants mais opaques n’obtiendront pas. La gouvernance des données, autrefois une préoccupation de back-office, devient partie intégrante de l’expérience produit.

Enfin, les modèles économiques pourraient passer de la vente de licences par utilisateur à la vente de résultats. Lorsque le logiciel fait le travail au lieu de simplement l’héberger, les clients paieront de plus en plus pour des résultats obtenus à partir de leurs données, plutôt que pour un accès à des écrans.

Ce que cela signifie pour les ingénieurs logiciel

Pour les ingénieurs, ce changement élève le niveau d’abstraction, un peu comme le passage de l’assembleur aux langages de haut niveau. Écrire à la main des écrans CRUD répétitifs, de la validation de formulaires et du code de liaison, c’est précisément le travail que l’IA fait bien. Le temps ainsi libéré se reporte sur les parties plus difficiles à automatiser.

La première est la donnée. Les ingénieurs qui maîtrisent la modélisation des données, les pipelines, la qualité, le lignage et le contrôle d’accès seront recherchés, car ils construisent le socle sur lequel repose chaque fonctionnalité d’IA. Savoir concevoir un schéma qui reste pertinent pendant dix ans vaut davantage que connaître un framework qui change tous les deux ans.

La deuxième est la pensée systémique et le jugement. Il faut toujours quelqu’un pour décider de ce qui doit être construit, de la manière dont les composants s’articulent, des domaines où l’IA est fiable et de ceux où elle a besoin de garde-fous, et de la façon d’évaluer si elle fonctionne. Rédiger des évaluations, relire du code généré et raisonner sur les modes de défaillance deviennent des compétences centrales plutôt que des tâches annexes.

La troisième est le sens du produit. À mesure que le coût de construction baisse, la compétence rare consiste à savoir ce qui mérite d’être construit et quelle expérience d’utilisation offrir. Les ingénieurs capables de parler aux utilisateurs, de comprendre leurs données et de traduire les deux en expériences claires feront le lien entre des rôles autrefois distincts : développeur, ingénieur de données et designer.

Les conseils pratiques en découlent. Apprenez la couche de données en profondeur. Traitez les outils d’IA comme des collaborateurs et apprenez à vous en servir avec aisance. Exercez-vous à formuler votre intention avec précision, car une spécification claire est désormais directement exécutable. Et entretenez vos fondamentaux, car relire du code écrit par une machine exige de le comprendre mieux qu’elle.

Conclusion

Le logiciel a commencé comme un ensemble d’instructions pour les machines, est devenu un produit pour les personnes, puis l’ensemble des interfaces par lesquelles presque toutes les entreprises fonctionnent. L’IA comprime aujourd’hui le coût du code et des écrans, révélant ce qui se trouvait dessous depuis le début : les données, et le travail qui consiste à les présenter pour que les humains puissent comprendre et décider.

Le logiciel et l’UX restent importants, avec une idée plus claire de leur finalité. Les meilleurs produits de la décennie à venir seront ceux qui détiendront les données les plus fiables et les présenteront avec le plus de clarté, en adaptant chaque vue à la personne et au moment. Pour le secteur, le rempart se déplace vers les données et la confiance. Pour les ingénieurs, le métier monte d’un niveau, de l’écriture de chaque ligne à la conception des systèmes, des données et des expériences qui rendent l’IA réellement utile.