La démo produit qui ne parlait pas vraiment du produit
L'année dernière, j'ai vu une équipe produit célébrer une mise en production qui ressemblait à une victoire technique propre. Elle avait construit un flux d'analyse assisté par IA pour traiter des demandes clients. La latence était meilleure, la transmission vers les opérations était plus fluide, et le tableau de bord était assez poli pour une démonstration exécutive.
Deux semaines plus tard, la vraie conversation a commencé.
Les agents du support disaient que le système poussait trop vite les clients impatients vers des réponses génériques. Les opérations constataient que le nouveau flux écartait des cas rédigés de manière inhabituelle alors qu'ils exigeaient encore une revue humaine urgente. Un manager a demandé pourquoi le modèle semblait plus à l'aise avec les personnes qui écrivaient dans un français corporate fluide qu'avec celles qui formulaient leur problème de façon plus brute, plus émotive ou plus mélangée.
Le produit fonctionnait. Le système autour du produit, non.
Ce moment résume pourquoi j'écris sur le logiciel et la société ensemble. Le code ne reste pas dans les dépôts. Il fuit dans les institutions, les habitudes, les incitations et la vie quotidienne. À partir du moment où le logiciel influence qui est vu, aidé, cru ou ignoré, la conversation n'est plus seulement technique.
Le logiciel est devenu une infrastructure sociale sans le dire
Nous parlons encore du logiciel comme d'un outil posé sur un bureau. En réalité, une grande partie se comporte maintenant comme une infrastructure. Il décide comment le travail est suivi, comment l'argent circule, comment les gens accèdent à des services publics, comment les enfants apprennent et comment les entreprises évaluent la performance.
Ce changement compte parce qu'une infrastructure modifie les comportements même quand personne n'annonce une grande théorie. Slack a changé les attentes de réponse avant que la plupart des équipes n'écrivent des règles d'asynchrone. Les systèmes de classement algorithmique ont transformé le recrutement et la visibilité avant que beaucoup de managers n'acceptent que le logiciel faisait déjà partie du management — une facette de la mort silencieuse de la fiche de poste. L'IA générative est en train de modifier la façon dont les équipes écrivent, décident, recherchent et jugent la qualité avant même que beaucoup de dirigeants aient défini ce qu'est une bonne supervision.
Quand le système influence les comportements à cette échelle, l'analyse technique seule devient trop étroite. On peut décrire correctement le modèle, l'API, l'architecture et la roadmap, et manquer quand même l'effet le plus important : ce que le système entraîne les gens à faire.
Un logiciel devient une question sociale au moment où il change les incitations à grande échelle.
Pour cette raison, je me méfie de la phrase : "Ce n'est qu'un outil." Les outils ne restent pas neutres une fois encastrés dans des institutions traversées par des rapports de pouvoir, des pressions de performance et des accès inégaux à la connaissance — l'argument que Lawrence Lessig défendait il y a des décennies en écrivant que le code fait loi(lien externe, nouvel onglet).
L'erreur de l'ingénieur et l'erreur du commentateur
Il existe deux manières faciles de se tromper.
La première est l'erreur de l'ingénieur : traiter chaque problème comme s'il devenait plus clair dès qu'on ajoute assez de détail technique. Parfois le détail aide. Parfois il masque le vrai sujet. Une équipe peut passer des semaines à débattre des bases vectorielles, des couches d'orchestration ou de la latence frontend tout en ignorant que le workflow qu'elle automatise est lui-même cassé, biaisé ou incohérent.
La seconde est l'erreur du commentateur : parler de société comme si la technologie n'était qu'un symbole. Cela produit des textes dramatiques et des analyses faibles. On ne peut pas comprendre ce que l'IA change dans le recrutement, la santé, l'éducation ou le travail produit si l'on ne s'intéresse pas à la façon dont les systèmes sont réellement assemblés, mesurés et déployés.
J'écris sur les deux surfaces parce que chacune corrige l'autre. La précision technique protège l'argument contre l'abstraction vide. L'analyse sociale le protège contre la vision en tunnel.
Ce que le travail produit m'a appris sur cette frontière
Le Product Ownership a rendu cela encore plus net. Un Product Owner vit exactement à la frontière où les possibilités techniques se heurtent aux priorités business et aux conséquences pour les utilisateurs — le cœur du mindset de product owner. On ne peut pas bien faire ce métier si l'on réduit les personnes à des tickets. On ne peut pas non plus bien le faire si l'on romantise les utilisateurs en ignorant les contraintes.
Chaque vrai backlog contient des choix sociaux déguisés en choix de livraison.
Quels utilisateurs sert-on d'abord quand les ressources sont limitées ? Quelle friction est jugée acceptable ? La confusion de qui devient un coût support et la confusion de qui est simplement ignorée ? Quel échec est traité comme un bug et lequel est traité comme une erreur utilisateur ?
Ce ne sont pas des notes de bas de page philosophiques. Elles sont intégrées dans la planification des releases, le choix des KPI, le design des workflows et la priorisation.
C'est aussi pour cela qu'une partie des conversations produit les plus importantes ressemblent aujourd'hui moins à des discussions de fonctionnalités qu'à des discussions de gouvernance. Pas de théâtre juridique. De la gouvernance au sens pratique : qui décide, sur quelles preuves, avec quels garde-fous, et avec quelle responsabilité quand le système échoue — la réalité opérationnelle que j'ai détaillée dans l'article sur l'AI Act européen pour les équipes produit. C'est aussi pourquoi les organisations professionnelles maintiennent quelque chose comme le Code d'éthique de l'ACM(lien externe, nouvel onglet).
Pourquoi cela compte encore plus à l'ère de l'IA
L'IA a renforcé la nécessité de ce regard parce qu'elle fait paraître le logiciel plus humain qu'il ne l'est réellement. Un moteur de règles fragile a l'air mécanique, donc les gens s'en méfient naturellement. Un assistant fluide a l'air compétent, donc les gens lui accordent trop de confiance. Cet écart entre l'apparence et la fiabilité réelle est un risque social avant d'être un risque technique.
Les exemples de terrain sont déjà partout. Des équipes se disent plus productives parce que les brouillons apparaissent plus vite, alors que le travail de revue explose en silence. Des entreprises célèbrent l'automatisation tout en déplaçant le traitement des exceptions vers des travailleurs moins visibles. Des dirigeants vantent leur stratégie IA pendant que les employés de première ligne absorbent l'ambiguïté, les reprises et le coût réputationnel des erreurs.
Si j'écris seulement sur la stack technique, je rate l'histoire du travail. Si j'écris seulement sur l'histoire du travail, je rate les choix de conception qui l'ont produite.
Écrire comme traduction, pas comme posture
Je ne m'intéresse pas à l'écriture sur la société parce que cela paraît plus large, plus noble ou plus intellectuel. Je le fais parce qu'il faut quelqu'un pour traduire entre des mondes qui continuent de faire semblant d'être séparés.
L'ingénieur doit comprendre que chaque décision d'architecture transporte des hypothèses sur les utilisateurs, les institutions et le pouvoir. Le manager doit comprendre que les slogans sur l'innovation s'effondrent vite quand le système de base est mal construit. Le citoyen a besoin d'un langage pour voir que les systèmes numériques ne sont pas des forces naturelles abstraites. Ils sont construits par des personnes, financés par des organisations et optimisés autour d'incitations qu'on peut interroger.
Une bonne écriture peut rendre cette traduction concrète. Elle peut prendre quelque chose qui paraît inévitable et montrer les arbitrages dessous. Elle peut prendre quelque chose qui paraît abstrait et montrer où cela atterrit dans la vie ordinaire.
C'est ce travail-là qui m'intéresse.
Le takeaway
J'écris sur le logiciel et la société dans le même souffle parce que la frontière entre les deux s'est déjà effondrée. La décision produit est aussi une décision organisationnelle. La décision d'interface est aussi une décision comportementale. La décision d'automatisation est aussi une décision sur le travail. Une fois qu'on le voit clairement, écrire seulement sur le code commence à sembler malhonnête.
La question intéressante n'est plus de savoir si la technologie est sociale. Elle est de savoir si nous sommes prêts à décrire ses conséquences sociales avec le même sérieux que celui que nous appliquons au design des systèmes.
