Je ne sais pas si vous avez entendu parler du sophisme du portier, mais il sévit actuellement dans tous les métiers liés à la programmation.
L’idée derrière ce sophisme est la suivante : imaginez un hôtel de luxe haut de gamme.
On y trouve souvent un portier qui ouvre et ferme la porte à chaque personne qui entre dans l’hôtel. En tant que manager, vous pourriez vous dire : « Pourquoi payons-nous quelqu’un 27 600 € pour ouvrir une porte alors que nous pourrions dépenser 5 € pour installer une butée et laisser la porte toujours ouverte ? » Vous décidez donc de licencier ce portier pour économiser 27 600 €.
Puis, six mois, un an, plusieurs années plus tard, vous commencez à constater une baisse de votre chiffre d’affaires. Et vous ne comprenez pas vraiment pourquoi, car rien d’autre n’a changé, à part le fait que vous avez licencié ce portier et que vous utilisez désormais une butée pour maintenir la porte ouverte. Ou peut-être avez-vous des portes automatiques, ou autre chose.
La raison pour laquelle ce licenciement a en réalité provoqué le déclin de votre entreprise est que ce portier ne se contentait pas d’ouvrir et de fermer des portes. En tant que manager, c’est ce que vous pensiez qu’il faisait, et c’est pour cela qu’il avait été embauché sur le papier. Mais en réalité, il faisait bien plus que cela.
Quelqu’un qui ouvre et ferme la porte pour vous lorsque vous entrez dans un hôtel semble prestigieux, et cela vous fait du bien, comme si vous vous disiez : « Oh, je suis une personne importante et de haut rang, puisque cette autre personne m’ouvre la porte. »
- Ce portier peut aussi prendre vos bagages
- discuter avec vous
- vous divertir pendant que vous attendez de vous enregistrer
Alors oui, il ouvre et ferme la porte, c’est ce que décrit sa fiche de poste. Mais il ajoute du prestige à votre hôtel simplement en se tenant là, même lorsqu’il n’ouvre pas la porte. Il améliore le ressenti de vos clients et leur fournit des services bien au-delà de ce que sa fiche de poste laisse imaginer.
Ainsi, ce licenciement du portier vous a peut-être fait croire que vous alliez économiser 27 600 €, car ouvrir et fermer une porte ne vaut pas 27 600 €. Mais ce portier faisait bien plus que cela.
Ce phénomène se produit également dans le domaine du logiciel
La plupart des gens pensent que la seule chose que font les programmeurs est d’écrire du code. Mais en réalité, écrire du code ne représente qu’une petite partie de ce que fait un développeur, et c’est sans doute l’une des parties les moins importantes du métier.
Écrire du code revient essentiellement à prendre tout ce que vous avez déjà planifié, réfléchi et fait, et à le rendre compréhensible par l’ordinateur. Mais la partie difficile, ce pour quoi les gens sont réellement payés en tant que développeurs logiciels, surtout à mesure que vous gagnez en séniorité, c’est la capacité à réfléchir.
Comment architecturer un système complet ? Comment planifier les éléments que vous devez construire par rapport à ceux que vous devez acheter ou utiliser via un tiers ? Comment vous assurer d’avoir un code maintenable et de haute qualité ? Ce sont toutes des choses sur lesquelles vous passez énormément de temps à réfléchir si vous êtes développeur logiciel.
Il y a une raison pour laquelle je garde toujours plusieurs tableaux blancs à côté de mon bureau et que j’ai souvent des blocs-notes à portée de main lorsque je programme : je passe plus de temps à réfléchir au code que je vais écrire qu’à l’écrire réellement. Et c’était le cas bien avant l’ère de l’IA.
Même lorsque j’écrivais chaque ligne de code à la main, je passais souvent beaucoup plus de temps à réfléchir à l’architecture, à planifier ce que le code allait faire, à m’assurer que toutes les tables de base de données et tout le reste correspondaient à ce que je voulais.
Une fois que j’avais fini de réfléchir et de planifier, alors seulement je me mettais à écrire le code. Puis je devais le relire, comprendre ce qui se passait à l’intérieur, et le remanier pour qu’il fonctionne mieux, je réalisais peut-être en l’écrivant que le grand plan que j’avais ne fonctionnait pas tout à fait à cause d’un certain élément.
Je devais alors reconfigurer mon code après coup. Et c’est essentiellement le processus de refactoring. Mais tout cela se produit avant que le code ne soit déployé pour la première fois.
- Il y a la planification
- puis l’écriture
- puis le refactoring
- puis l’écriture
…peut-être plus de refactoring et d’écriture, plus de planification, puis d’écriture, et enfin je peux déployer mon code. Ensuite, quelqu’un d’autre, généralement un développeur plus senior ou de même niveau, va parcourir et lire tout ce code.
Le temps réellement passé à écrire du code, même avant l’ère de l’IA, était si faible par rapport au temps passé à lire du code, au temps passé à réfléchir au code, au temps passé à planifier l’architecture, à s’assurer que les pratiques de code propre sont comprises. Ce sont ces éléments qui permettent aux applications à grande échelle d’être maintenues sur 10, 20, voire 30 ans ou plus.
Ce sont les compétences que possèdent la plupart des développeurs, mais que la plupart des managers ne réalisent pas être importantes. Ils pensent : « La quantité de code que vous écrivez est la chose la plus importante », alors que nous savons tous que cela ne signifie absolument rien.
J’irais presque jusqu’à dire que le nombre de lignes de code est une mesure inverse de la qualité du code. Généralement, si vous écrivez des tonnes de code, cela représente simplement davantage d’éléments à maintenir.
Certaines personnes considèrent que le nombre de tokens est la mesure de votre productivité en tant que développeur. Nous sommes payés pour réfléchir, résoudre des problèmes et concevoir l’architecture. L’écriture du code n’est que le sous-produit de l’expression de ces différentes compétences.
Même si l’IA arrivait et prenait en charge toute l’écriture du code par les développeurs, cela ne signifie pas que nous n’avons plus besoin de développeurs. Toutes ces autres compétences sont ce pour quoi vous êtes payé. Et je pense que ces entreprises qui décident qu’elles n’ont pas besoin d’autant de programmeurs parce qu’elles peuvent faire écrire le code par l’IA vont se retrouver dans une situation difficile d’ici quelques années, lorsqu’elles réaliseront que tout leur code est écrit et fonctionne, mais qu’il est très mal architecturé, très difficile à maintenir, et truffé de bogues… car elles ne disposent pas de ces développeurs logiciels pour gérer et concevoir l’architecture de ce que le code est censé devenir.
Le sophisme du portier dans la technologie d’entreprise
🔐 Conseil pratique
Pour Comment vous assurer d’avoir un code maintenable et de haute qualité, commencez par les bases avant de viser l’expertise. La constance bat l’intensité (un petit geste répété vaut mieux qu’un gros effort ponctuel.)
Un VPN protege votre vie privee en ligne et securise vos donnees sur les reseaux publics (Wi-Fi gratuit, hotspot, etc.). Si vous cherchez un VPN sans vous ruiner, ProtonVPN a une offre gratuite illimitee (pas de limite de data, pas de carte bancaire).
Ce sophisme ne se limite pas aux hôtels ou au développement logiciel. Il est partout, y compris dans la technologie d’entreprise.
Rory Sutherland, dans son livre Alchimie, explique ce phénomène avec une métaphore qui parle à tout le monde : un hôtel cinq étoiles remplace son portier souriant par une porte coulissante automatique. Logique sur le papier : ça coûte moins cher, c’est plus rapide, pas de pauses déjeuner. Mais les clients commencent à se plaindre, les audiences chutent, les VIP ne reviennent plus. Pourquoi ? Parce que le portier ne se contentait pas d’ouvrir la porte : il apportait un sourire, un sentiment de sécurité, une impression d’être important. La porte automatique, elle, ne fait que s’ouvrir.
Dans la tech d’entreprise, on ne regarde que ce qui se mesure, et on jette le reste. Ouvrons la porte en grand (jeu de mots voulu) et regardons comment cela se déroule, et comment vous pouvez l’éviter.
Automatisation du support informatique : le chatbot qui ne comprend rien
Un nouveau chatbot remplace le helpdesk informatique. Il répond instantanément aux questions simples, économise de l’argent, jusqu’à ce que vous tombiez sur un vrai problème.
Soudain, vous vous retrouvez en spirale dans des boucles automatisées, à crier « Parle à un humain ! ». Les chatbots gèrent les requêtes de routine comme des champions, mais ils ne remplacent pas le technicien empathique qui vous rassure pendant qu’il répare une crise système. L’humain apporte du réconfort, de la confiance, et gère les zones grises que les bots ne comprennent tout simplement pas.
Systèmes legacy : le héros silencieux qu’on veut jeter
Tout le monde aime un jouet tout neuf et brillant. Alors pourquoi garder ce vieux système legacy maladroit, lent et cher ? Parce que ces systèmes hérités sont souvent les héros silencieux de vos opérations :
- ils sont stables,
- profondément intégrés,
- et éprouvés par des années de combat.
Les abandonner complètement peut entraîner des perturbations coûteuses. La meilleure approche n’est pas de choisir entre l’ancien et le nouveau, mais de mixer les deux : garder l’ancien pour la stabilité, ajouter le nouveau pour l’innovation. Un système hybride, pas une décision binaire à la hache.
Le ROI ne dit pas tout : les dieux du tableau Excel
Le retour sur investissement est la divinité absolue dans les salles de réunion. Mais c’est un peu comme juger une maison uniquement sur le nombre de briques dans ses murs : vous oubliez la cheminée douillette, la balançoire dans le jardin, la vue incroyable.
Les investissements tech (un CRM performant, un bon outil de monitoring) ne montrent pas toujours un ROI immédiat, mais ils créent de la valeur autrement : des relations clients plus solides, des employés plus heureux, de la loyauté à long terme. Parfois, les meilleurs rendements ne se voient pas dans un tableau Excel.
Les petits détails invisibles font une grande différence
L’UX/UI, c’est plus que de jolis pixels. Vous n’achèteriez pas une voiture avec un volant difficile à tourner, même si elle vous mène du point A au point B. Alors pourquoi se contenter d’un logiciel d’entreprise lourd et mal conçu ?
Une bonne expérience utilisateur réduit la frustration, augmente la productivité et fait dire aux employés : « Cet outil facilite vraiment mon travail. » Résultat : les taux d’adoption explosent, et le ROI réel dépasse largement ce que les tableaux Excel laissent prévoir.
Le talon d’Achille de l’automatisation
L’automatisation est la chouchoute de la technologie d’entreprise.
La RPA (automatisation robotisée des processus) peut traiter des données et gérer des tâches répétitives plus vite que vous ne pouvez dire « feuille Excel ». Mais c’est là que le sophisme du portier entre en jeu : les humains ne font pas que des transactions. Ils repèrent les anomalies, comprennent le contexte, prennent des décisions nuancées.
Les remplacer complètement par des robots, c’est comme remplacer un portier par une butée de porte : vous perdez la capacité d’adaptation, le jugement et l’empathie qui font la différence.
Comment éviter le sophisme du portier dans vos décisions
Alors, comment éviter de tomber dans ce piège ? Trois pistes concrètes :
- Cartographiez la valeur cachée : Avant de supprimer un poste ou un outil, listez tout ce qu’il apporte vraiment, pas seulement sa fonction officielle. Un développeur expérimenté ne fait pas que coder : il mentore, il anticipe les problèmes, il conçoit l’architecture.
- Testez avant de supprimer : Plutôt que de remplacer brutalement une équipe ou un système, faites un pilote. Comparez les résultats sur un trimestre. Vous verrez souvent que le « vieux » système apporte des bénéfices invisibles.
- Écoutez les opérationnels : Les managers voient les KPI, mais les équipes terrain voient la réalité. Un technicien support saura vous dire pourquoi le chatbot ne remplace pas l’humain. Prenez le temps de les entendre.
Comment le sophisme du portier tue la qualité logicielle
Revenons au développement logiciel, puisque c’est le cœur du sujet. Le sophisme du portier y fait des ravages, surtout depuis l’arrivée massive de l’IA générative.
Les managers regardent le nombre de lignes de code produites par jour, ou le nombre de tokens générés, et ils se disent : « Super, avec l’IA, un développeur fait le travail de trois. On peut donc licencier les deux autres. » C’est exactement la même erreur que le portier. L’IA écrit du code, oui. Mais qui conçoit l’architecture ? Qui valide que le code ne contient pas de failles de sécurité ? Qui s’assure que le code est maintenable dans 5 ans ?
Le vrai travail du développeur
Voici ce que fait réellement un développeur senior, au-delà de l’écriture de code :
- Conception architecturale : Choisir les bonnes technologies, structurer les dépendances, anticiper la scalabilité.
- Revue de code : Lire le code des autres, détecter les bugs, les incohérences, les mauvaises pratiques.
- Mentorat : Former les juniors, partager les bonnes pratiques, éviter les erreurs coûteuses.
- Résolution de problèmes complexes : Déboguer des bugs qui n’apparaissent qu’en production, optimiser des requêtes lentes, gérer les incidents.
- Communication : Traduire les besoins métier en spécifications techniques, négocier avec les parties prenantes.
Tout cela, une IA ne le fait pas. Pas encore, et probablement pas avant longtemps.
| Compétence | Rôle du développeur humain | Peut être remplacé par l’IA ? |
|---|---|---|
| Écriture de code | Exécution de la conception | Oui, en grande partie |
| Conception architecturale | Choix techniques, scalabilité | Non, nécessite vision et contexte |
| Revue de code | Détection de bugs, sécurité | Partiellement, mais pas fiable seul |
| Mentorat | Transmission de savoir | Non, nécessite empathie |
| Résolution de problèmes complexes | Debug, optimisation, incidents | Non, nécessite jugement |
Le piège des métriques superficielles
Quand on mesure la productivité d’un développeur uniquement par le nombre de lignes de code ou de tokens générés, on tombe dans le sophisme du portier. On ne voit que la partie émergée de l’iceberg. On ignore la valeur cachée :
- la réflexion,
- la conception,
- la maintenance,
- la communication.
Les entreprises qui licencient des développeurs en masse en pensant que l’IA va les remplacer vont se retrouver avec du code mal architecturé, difficile à maintenir, et bourré de bugs. Elles vont payer cher cette erreur, en coûts de maintenance, en temps perdu, et en opportunités manquées.
J'ai teste pas mal de VPN au fil des annees, et ProtonVPN est celui que j'ai garde. Open source (code audite), base en Suisse (lois RGPD parmi les plus strictes au monde), et surtout une version gratuite sans limite de data (pas besoin de carte bancaire). Le rapport qualite-prix est imbattable.
Conclusion : ne remplacez pas le portier
Le sophisme du portier nous rappelle une leçon simple mais puissante : ce qui est visible et mesurable n’est pas toujours ce qui a le plus de valeur. Dans la technologie d’entreprise comme dans le développement logiciel, les rôles humains apportent une richesse bien au-delà de leur description de poste officielle.
Avant de prendre une décision de réduction d’effectifs ou d’automatisation, prenez le temps de cartographier toute la valeur apportée. Écoutez les équipes terrain. Testez avant de supprimer. Sinon, vous risquez de remplacer un portier qui faisait bien plus que tenir la porte, par une butée qui ne fait que ça.
Comment identifier le sophisme du portier dans mon entreprise ?
Posez-vous la question : « Qu’est-ce que cette personne ou cet outil apporte vraiment, au-delà de sa fonction officielle ? » Listez les bénéfices invisibles : mentorat, stabilité, confiance, adaptabilité. Si la réponse est « beaucoup de choses non mesurables », vous êtes probablement face à ce sophisme.
L’IA ne remplacera-t-elle jamais les développeurs ?
L’IA remplace déjà une partie du travail d’écriture de code. Mais la conception, l’architecture, la résolution de problèmes complexes et le mentorat restent des compétences humaines essentielles. Les entreprises qui misent tout sur l’IA sans garder des développeurs expérimentés risquent de se retrouver avec un code ingérable à long terme.
