Dans un café, le menu s’affiche sur un QR code. Dans un entrepôt, un écran répartit les commandes entre des chariots. Dans un cabinet médical, une interface organise les rendez-vous, les dossiers et les rappels. Rien de tout cela ne ressemble spontanément à une entreprise de logiciel. Pourtant, c’est précisément l’idée contenue dans la formule devenue célèbre : « Software is eating the world ».
La phrase peut sembler datée, presque trop évidente à l’heure où chaque activité possède son application, son tableau de bord et ses notifications. Mais elle reste un excellent instrument de lecture. À condition de ne pas la comprendre comme une prophétie technophile simpliste. Le logiciel ne « mange » pas le monde parce qu’il remplace magiquement les métiers, les lieux et les relations humaines. Il le transforme en reconfigurant les règles par lesquelles ils fonctionnent.
« Software is eating the world » : le logiciel devient une couche active de plus en plus d’activités économiques et sociales.
Une formule volontairement brutale, une idée plus fine
Prise littéralement, la formule suggère une conquête totale : les entreprises de logiciel absorberaient toutes les autres. Cette lecture a nourri bien des fantasmes, depuis la start-up censée « disrupter » n’importe quel secteur jusqu’à l’idée que tout problème humain appellerait une plateforme.
Son intérêt réel est ailleurs. Le logiciel agit comme un système de coordination. Il permet de saisir une information, de la stocker, de la comparer, de déclencher une action, de mesurer un résultat et de recommencer. Dès qu’une activité comporte des flux répétitifs, des décisions récurrentes ou des ressources à répartir, elle devient partiellement programmable.
Un hôtel ne devient pas une entreprise de technologie parce qu’il propose une réservation en ligne. En revanche, il se met à fonctionner différemment lorsque son taux d’occupation, ses tarifs, son planning de ménage, ses avis clients et ses canaux de distribution sont reliés par des outils numériques. Le logiciel ne constitue pas forcément le produit final ; il devient souvent l’infrastructure invisible qui organise ce produit.
Cette distinction est essentielle. Elle évite deux erreurs symétriques : réduire le numérique à un simple site web, ou imaginer qu’un outil suffit à transformer une organisation. Le logiciel est puissant lorsqu’il s’insère dans une pratique réelle : servir un client, acheminer un colis, soigner un patient, produire un objet, enseigner, recruter ou décider.
Quand l’activité devient lisible par une machine
Pour qu’un domaine soit travaillé par le logiciel, il doit d’abord être rendu lisible. Les gestes, les stocks, les demandes, les délais, les documents et les exceptions doivent pouvoir être décrits sous forme de données. C’est le mouvement de numérisation, mais aussi de normalisation : donner des noms communs à des choses qui étaient autrefois dispersées, tacites ou dépendantes d’une mémoire individuelle.
Cette étape est rarement neutre. Mettre en données une activité oblige à trancher. Qu’est-ce qu’un client actif ? Quand une commande est-elle réellement terminée ? Quel événement compte comme un incident ? Quelles catégories doit-on utiliser ? Derrière un tableau de bord apparemment objectif se cachent toujours des choix de vocabulaire, de seuils et de priorités.
C’est pourquoi les bons projets numériques commencent moins par la question « quel outil acheter ? » que par une enquête sur le travail réel. Il faut regarder les contournements, les carnets personnels, les appels téléphoniques, les fichiers parallèles et les décisions prises au jugé. Ils signalent souvent ce que le système officiel ne parvient pas à représenter.
Le logiciel apporte de la rigueur, mais il peut aussi rigidifier. Une procédure numérisée trop tôt fige parfois une mauvaise habitude. À l’inverse, une activité laissée entièrement informelle devient difficile à transmettre, à auditer ou à améliorer. Tout l’enjeu consiste à formaliser assez pour apprendre collectivement, sans prétendre enfermer le réel dans des cases définitives.
Le vrai changement : des produits qui continuent d’agir après la vente
Dans l’économie industrielle classique, un produit est souvent livré, utilisé, réparé puis remplacé. Avec le logiciel, il peut être modifié après sa mise à disposition. Une interface évolue, une fonction apparaît, une règle de calcul est ajustée, un défaut est corrigé. Cette capacité de mise à jour change profondément le rapport entre concepteur et utilisateur.
Le produit n’est plus seulement un objet achevé : il devient un produit évolutif. Cette évolution peut être bénéfique, car elle permet de corriger rapidement des erreurs et d’adapter un service à de nouveaux besoins. Mais elle peut également déstabiliser : une fonctionnalité familière disparaît, une condition d’accès change, une décision jusque-là humaine est automatisée sans véritable discussion.
Cette logique explique l’importance prise par les modèles d’abonnement, les services en ligne et les plateformes. Le revenu ne dépend plus uniquement de l’instant de vente ; il dépend de la continuité d’usage. Les entreprises cherchent alors à rester présentes dans le quotidien de leurs clients, parfois en leur offrant une valeur durable, parfois en créant une dépendance difficile à quitter.
La question pertinente n’est donc pas seulement : « Est-ce numérique ? » Elle est : « Qui peut modifier les règles du service, à quel rythme, et avec quel contrôle de la part des usagers ? » Le pouvoir du logiciel réside largement dans cette capacité à reconfigurer les conditions d’une activité à distance.
Les données ne sont pas le pétrole : elles sont une trace de l’activité
La métaphore du pétrole a longtemps dominé les discours sur les données. Elle est séduisante, mais trompeuse. Une donnée ne vaut rien par elle-même, ni même forcément par son volume. Elle devient utile lorsqu’elle est liée à une décision, à un contexte et à une action possible.
Une liste de clics ne dit pas, à elle seule, ce qu’un utilisateur cherche. Un historique d’achats ne révèle pas automatiquement une intention. Un indicateur de productivité peut confondre vitesse et qualité. Les données sont des traces, souvent incomplètes, de comportements situés. Elles demandent de l’interprétation.
La force des organisations dites data-driven ne devrait donc pas se mesurer à la quantité de chiffres qu’elles produisent, mais à leur capacité à formuler de meilleures questions. Quel problème tentons-nous de résoudre ? Que ne voyons-nous pas dans cet indicateur ? Quelle décision changerions-nous si cette mesure variait ?
Un tableau de bord utile réduit l’incertitude. Un mauvais tableau de bord la déguise sous des couleurs rassurantes. Dans un monde mangé par le logiciel, l’esprit critique ne devient pas moins nécessaire : il doit apprendre à lire les interfaces, les métriques et les classements comme des constructions, non comme des verdicts.
Les interfaces deviennent des lieux de pouvoir
Autrefois, une grande part du pouvoir organisationnel se logeait dans les bureaux, les règlements et les hiérarchies visibles. Aujourd’hui, il s’exerce aussi dans l’interface. L’écran décide de ce qui est facile ou pénible, visible ou caché, possible ou interdit. Un bouton placé en évidence peut orienter un comportement aussi sûrement qu’une consigne explicite.
Le design n’est donc pas un habillage final. Il est une politique miniature. Lorsqu’une plateforme recommande un contenu, fixe un ordre d’affichage, impose un formulaire ou évalue une prestation, elle distribue de l’attention, du temps et parfois des revenus. Ses règles ne sont pas toujours écrites dans un règlement : elles sont incorporées dans des parcours d’usage.
Cette réalité exige une nouvelle forme de culture générale. Comprendre le logiciel ne signifie pas savoir programmer. Cela signifie savoir repérer une automatisation, interroger une recommandation, demander quelles données alimentent une décision et identifier les intérêts servis par une architecture technique.
- Une automatisation permet-elle de gagner du temps sans supprimer une vérification nécessaire ?
- Les personnes concernées peuvent-elles comprendre, corriger ou contester une décision ?
- Le système rend-il le travail plus coopératif, ou seulement plus mesurable ?
- Que se passe-t-il lorsque l’outil tombe en panne, change de règles ou disparaît ?
Ce que la formule oublie : le monde résiste
Le logiciel excelle dans les environnements où les règles sont explicites et les retours mesurables. Il est moins à l’aise avec ce qui relève du jugement, du soin, de la négociation, de l’imprévu ou de la confiance. Une application peut organiser une tournée ; elle ne remplace pas nécessairement la connaissance d’un quartier, l’attention à une personne fragile ou l’intelligence d’une situation exceptionnelle.
Cette limite n’est pas un échec du numérique. C’est un rappel salutaire : toutes les activités ne sont pas réductibles à une suite d’instructions. Une organisation mature ne cherche pas à automatiser pour automatiser. Elle distingue ce qui doit être stable de ce qui doit rester discutable, ce qui gagne à être accéléré de ce qui mérite du temps.
La meilleure question à poser face à tout nouvel outil est peut-être la plus simple : quelle capacité humaine voulons-nous augmenter, et laquelle risquons-nous d’atrophier ? Un bon logiciel peut libérer de l’attention pour le travail qui compte. Un mauvais système transforme des professionnels compétents en opérateurs chargés de satisfaire une machine.
Ne pas subir le logiciel, apprendre à le gouverner
« Software is eating the world » n’annonce pas la disparition du monde matériel, des institutions ou des métiers. Il décrit leur mise en relation croissante avec des couches de code, de données et de règles automatisées. Le logiciel s’étend parce qu’il rend certaines opérations reproductibles, observables et modifiables.
Mais ce mouvement n’a rien d’inéluctablement positif. Les programmes incorporent des choix ; les plateformes créent des dépendances ; les métriques déplacent les priorités. La réponse n’est ni le rejet nostalgique, ni l’adhésion automatique. Elle passe par une gouvernance plus attentive : décider quelles tâches déléguer, préserver des recours humains, rendre les règles compréhensibles et maintenir la possibilité de sortir d’un système.
La formule reste féconde si on la retourne légèrement. Le logiciel mange le monde, certes. Mais le monde continue de nourrir le logiciel : par son travail, ses données, ses conventions, ses conflits et ses besoins. C’est là que se joue l’essentiel. Pas dans la fascination pour le code, mais dans notre capacité collective à choisir ce qu’il doit réellement organiser.
