Mot-clé - affordancetrompeuse

Fil des billets - Fil des commentaires

samedi 25 septembre 2021

Affordance trompeuse : API

Une API est une interface (i.e. la frontière entre deux choses) utilisée dans l'action de programmer des applications. On décrit la liste des opérations disponibles, avec pour chacune ce dont on a besoin, et ce qu'on aura en retour. Pour les informaticiens et en version longue, ça se passe du côté de C'est le printemps, bientôt les API vont éclore, sinon restez ici.

Analogie dans le monde du spectacle :

  • L'opération "donner un concert" demande des artistes et des instruments, et permet d'obtenir en retour un concert
  • L'opération "donner un encore" demande des artistes en tenue décontractée et des instruments, et permet d'obtenir en retour un encore

La tromperie est dans le fait d'utiliser le terme API pour désigner l'exécution de l'opération. En langage courant :

  • "Je suis allé à donner un concert hier soir, c'était génial ! On était très près de la scène pour le donner un encore, un grand moment de communion !"
  • "Venez tous à la pendaison de crémaillère pour fêter l'emménagement dans notre nouvelle signature d'un acte de vente !"

Ou en faisant la confusion dans l'autre sens :

  • "J'ai été déçu par cette interprétation à la Philarmonie, trop de fausses notes dans la partition."
  • "On a une grosse fuite d'eau, c'est un vice caché du schéma de plomberie"

Pour les informaticiens utilisant API en ce sens, allez leur demander la différence entre GPL et LGPL, la tromperie deviendra limpide. Ils ne pourront pas se baser sur Wikipedia étant donné que les pages françaises et anglaises sur la LGPL font l'impasse sur le terme "interface", qui est la clef de voûte de cette différence.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

dimanche 2 mai 2021

Affordance trompeuse : dette technique

Depuis quelques années, le vocable "dette technique" est à la mode. Dans le langage commun du développeur, ce terme est synonyme de tout ce qui ne lui plaît pas dans le code, et que le méchant management ne lui laisse pas changer. Les causes d'insatisfactions sont nombreuses, ceci allant du non-respect des "bonnes pratiques" jusqu'au #cépamoderne en passant par la volonté de faire de la compta en virgule flottante. Pourquoi ce nom de dette technique ? On se verra répondre que si on ne le fait pas (sous-entendu, le bien), alors on le paiera plus tard. Soit. Mais selon quelles modalités ? Est-ce grave de payer plus tard si cela est sans frais ? La modernité dans la tech ayant une durée de vie de six mois, est-ce qu'il ne vaudrait pas mieux attendre ? Devant une telle définition de la dette technique, on est effectivement tenté de répondre avec une locution à peu près aussi définie : un tiens vaut mieux que deux tu l'auras.

On peut se demander si cette expression est arrivée à être diffusée uniquement sur sa proposition de "boîte à contrariétés". La réponse est évidemment non, sinon on ne serait pas dans la série des affordances trompeuses. Presque vingt ans après avoir créé cette métaphore, Ward Cunningham l'explique très bien dans cette courte vidéo. Celle-ci n'ayant pas de sous-titres français, et devant l'absurdité de regarder une image mouvante pour ce qui tient en quelques lignes, je vous en propose ici une transcription traduite.

J'ai commencé à m'intéresser à la façon dont les métaphores influencent notre façon de penser après la lecture de "Metaphors We Live By" de George Lakoff et Mark Johnson. Une idée importante est que nous raisonnons par analogie avec les métaphores qui sont entrées dans notre langage.

 

J'ai inventé la métaphore de la dette pour expliquer la refactorisation que nous faisions sur le produit WyCash. C'était un produit développé en Digital Smalltalk et il était important pour moi que nous reflétions les connaissances acquises à propos de l'application au cours du temps, en modifiant le programme pour qu'il ait l'air d'avoir été écrit comme si nous avions eu cette connaissance depuis le début, et comme si c'était la façon naturelle de le faire en Smalltalk.

 

L'explication que j'ai donné à mon chef, et on parle de logiciel dans le domaine de la finance, était une analogie financière que j'ai appelée la métaphore de la dette, qui dit que si l'on échoue à aligner notre programme avec ce que l'on a compris de la bonne façon de penser nos objets financiers, alors nous allions continuellement buter sur cette divergence, et que cela nous ralentirait de la même manière que de payer les intérêts d'un emprunt.

 

En empruntant de l'argent vous pouvez faire des choses plus vite que sans, mais jusqu'au remboursement complet, vous payez des intérêts. Je pensais qu'emprunter de l'argent était une bonne idée. Je pensais que se dépêcher de sortir le logiciel pour avoir de l'expérience avec était une bonne idée mais, évidemment, vous devez finalement revenir en arrière et, à mesure que vous apprenez des choses sur ce logiciel, vous allez rembourser cette dette en refactorisant le programme pour refléter cette expérience acquise.

 

Je pense que dans de nombreux cas les gens se dépêchent de sortir le logiciel et n'y réintègrent pas cet apprentissage, et par analogie, ont emprunté de l'argent sans avoir l'intention de le rembourser. Il va sans dire que si vous faites ça avec votre carte de crédit, à la fin toutes vos rentrées d'argent partent dans les intérêts, et votre pouvoir d'achat est nul.

 

Dans le même ordre d'idées, si vous développez un programme pendant longtemps en ne faisant qu'ajouter des fonctionnalités, et que jamais vous ne le réorganisez pour refléter votre compréhension de ces fonctionnalités, alors il arrivera un moment où il n'y aura plus de cohésion dans le programme, les efforts pour travailler dessus prendront de plus en plus de temps. En d'autres termes, les intérêts occuperont toutes vos rentrées et vous ne progresserez plus.

 

Beaucoup de personnes, tout du moins de bloggueurs, ont expliqué la métaphore de la dette en, je pense, la confondant avec l'idée que l'on peut écrire vite-fait du code avec l'intention de faire mieux plus tard, et que ceci était la première cause d'endettement. Je ne suis jamais pour écrire du code vite-fait, je suis pour écrire du code qui reflète votre compréhension présente d'un problème, même si cette compréhension est incomplète.

 

Si vous souhaitez vous endetter en développant un logiciel que vous ne comprenez pas complètement, alors il est sage de faire un logiciel qui reflète au mieux votre compréhension. Quand le temps de la refactorisation arrive, cela permet de voir clairement ce que vous pensiez alors et ainsi de rendre plus facile la transformation en ce que vous pensez désormais.

 

En d'autres termes, cette métaphore de la dette, ou de la capacité à rembourser la dette, pour qu'elle puisse fonctionner pour vous, dépend de votre capacité à écrire du code suffisamment propre pour pouvoir être refactorisé une fois que vous aurez compris le problème.

 

Je pense que c'est une bonne méthodologie qui est au cœur de l'eXtreme Programming. La métaphore de la dette est une des nombreuses explications au fait que l'eXtreme Programming fonctionne.

La dette technique actuelle est donc une version allégée, fade et sans réel intérêt, de la métaphore de la dette de Cunningham, qui est, elle, une justification de l'amélioration continue appliquée au développement logiciel, en partant du principe que si l'on n'a pas la compréhension nécessaire pour finir la conception, on peut quand même développer le logiciel (en s'endettant), à condition de revenir sur cette conception une fois que cette compréhension est acquise (remboursement de la dette). La métaphore de la dette est une question de gestion de la connaissance.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

mercredi 28 avril 2021

Affordance trompeuse : la qualité

La "qualité" est un grand mème des programmeurs, qui n'est jamais trop loin de son compagnon "modernité". Les grincheux me reprocheront ici normalement d'ergoter sans raison, parce que la qualité c'est le bien, et le bien doit être encouragé. C'est justement là que se situe la tromperie.

Comme il nous est rappelé dans le TLFi, la qualité est premièrement une caractéristique de nature, bonne ou mauvaise, d'une chose ou d'une personne. Bonne ou mauvaise. Parler de qualité n'est pas parler ni du bien ni du mal, parler de qualité n'est pas parler de moralité d'une chose, mais de sa caractérisation par rapport à sa nature, à son être.

Le travail de programmation n'implique d'ailleurs qu'à la marge ce travail de caractérisation. Par contre, il est important pour le programmeur d'arriver à produire quelque chose de conforme à la caractérisation attendue, aux qualités attendues. Ceci est l'activité d'assurance qualité. Et quand cette assurance qualité conclut à un résultat positif, alors on peut dire qu'on est en face d'un logiciel "de qualité", c'est-à-dire qu'il se comporte comme on le souhaite, ou plus précisément, conformément aux souhaits exprimés. Dans la pratique, cela revient à démontrer que l'on répond aux exigences, soit par une preuve formelle, soit par des tests. Bon, ne nous voilons pas la face, ça fait bien longtemps que l'industrie a fait une croix sur les preuves formelles, ça demande beaucoup trop de travail et personne n'a trouvé de belles photos dans les banques d'images pour mettre ça en diapositives dans des conférences inspirantes.

Est-ce que le fait que Facebook continue de me bombarder de photos de chats, après dix ans d'expression continue de mon désintérêt voire mon aversion envers cette pratique cruelle de garder en captivité des OGM carnivores, en fait un logiciel de mauvaise qualité ? On ne peut répondre correctement à cette question qu'en ayant connaissance du comportement attendu par ses concepteurs. Contrairement à l'utilisation courante du terme, la qualité en informatique est pensée, décidée, en un mot, conçue : ça n'est pas une projection de valeurs morales sur le produit ou le service.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

dimanche 24 janvier 2021

Affordance trompeuse : le data center

Après quelques aller-retours ces 40 ou 50 dernières années, le data center est à nouveau à la mode, en particulier parce qu'il se doit d'être vert. Le data center est en effet aujourd'hui le lieu où se matérialise le cloud computing. Data ? Computing ? Cela vous rappelle évidemment l'affordance trompeuse LA DATA ! Autant LA DATA est trompeur en français, autant data center l'est dans sa langue d'origine, et on peut légitimement se demander si cela a toujours été le cas. Le Web est (comme souvent) assez pauvre sur l'origine des termes informatiques, mais en cherchant un peu, on arrive relativement vite sur le cas des World Data Center créés en 1957. L'histoire de leur établissement peut être découverte dans The Origins and Principles of the World Data Center System, dont provient l'extrait ci-dessous :

At its decisive meeting in Brussels in 1955, when the Soviet Union officially unveiled its IGY programs, CSAGI set up a special Committee on the Availability of Data. This Committee recommended that data centers be set up in different countries as depositories and dissemination points for IGY data. The data would be collected and made available to any scientists without condition except for the cost of reproduction and mailing. The Committee recommended that CSAGI publish guides to the depositories and the types of data available from each. These World Data Centers would be more than passive depositories. They would actively supply data and provide the necessary facilities for data analysis.

Lors de sa réunion décisive à Bruxelles en 1955, lorsque l'Union soviétique dévoila officiellement ses programmes pour l'Année Géophysique Internationale (IGY), le Comité Spécial de l’Année Géophysique Internationale (CSAGI) a mis en place un comité spécial sur la disponibilité des données. Ce comité a recommandé que des centres de données soient créés dans différents pays en tant que dépositaires et points de diffusion des données de l'IGY. Les données seraient collectées et mises à la disposition de tous les scientifiques sans condition, à l'exception des frais de reproduction et d'envoi. Le comité a recommandé que le CSAGI publie des guides sur les dépositaires et les types de données disponibles pour chacun. Ces centres mondiaux de données seraient plus que des dépositaires passifs. Ils fourniraient activement des données et fourniraient les installations nécessaires pour l'analyse des données.

Ne nous méprenons pas, on parle déjà à l'époque d'automatisation du traitement des données, et de données numériques (sur cartes perforées), voire des premiers computer facilities : nous étions toujours en plein dans l'ère de la mécanographie. Le terme de data center est très probablement arrivé avant, mais à la fin des années 50, il paraît assez clair que quand on parle de ces data center, c'est pour désigner une stratégie proactive de centralisation des données dans un dépôt défini et géré par des sachant, afin de pouvoir les mettre en valeur. Le premier sujet tourne autour de la non-perte des données et de leur partage, un but proéminent après le succès relatif de la deuxième Année Polaire Internationale (API).

Rien de cela dans le data center d'aujourd'hui, qui n'est plus qu'un bâtiment connecté à Internet, bien refroidi, et rempli de serveurs, quelles que soient leurs utilisations.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

vendredi 8 janvier 2021

Affordance trompeuse : le cache

Selon un usage entériné par la commission d’enrichissement de la langue française dans le journal officiel en 2007, nous sommes censés parler du cache quand on évoque cet espace mémoire temporaire.

Le terme anglais est apparu avec le System/360 d’IBM pour le Model 85 commercialisé en 1968 (un modèle très flower power donc), soit la même année que CICS. Voici ce qu’on pouvait trouver dans Structural Aspects of the System/360 Model 85 II: The Cache pour cette année vraiment révolutionnaire à tout point de vue :

The storage hierarchy consists of a 1.04-microsecond main storage and a small, fast store called a cache, which is integrated into the CPU. The cache is not addressable by a program, but rather is used to hold the contents of those portions of main storage that are currently being used.

The term cache is synonymous with high-speed buffer, as used in other Model 85 documentation.

Ce terme cache est donc utilisé pour désigner un lieu où l’on peut mettre de l’information, et ce lieu n’est pas visible par tous. En français, cela s’appelle une cache ou une cachette. A contrario, un cache est quelque chose qui va masquer, et certainement pas un contenant.

L'utilisation du masculin pour cache va donc à l'encontre du sens français de cache. Et d'ailleurs, d'où vient ce mot anglais cache ? Selon Lexico, du verbe français cacher, verbe qu'on peut appliquer à la cache, ou au cache : balle au centre :-)


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Cet article a déjà été publié sous une autre forme ici.

samedi 2 janvier 2021

Affordance trompeuse : GitOps

Dans la lignée de la revalorisation du travail des opérateurs est née la mouvance GitOps, à savoir les relations particulières entre les opérateurs et les connards (traduction littérale de git). En fait pas vraiment, comme le disent les créateurs de GitOps (Weaveworks) dans leur article de 2017, GitOps consiste en la mise en œuvre d'une approche déclarative pour décrire ce que l'on souhaite dans son système, puis de détecter les changements, et d'agir en conséquence en fonction des changements demandés. Vous aurez bien évidemment reconnu l'approche CFEngine de 1993, en un peu moins puissant, dans le sens où en GitOps les différences sont évaluées cible par cible, et pas de manière systémique ; ici on parle de cible d'outillage de déploiement et pas cible finale.

Est-ce que Git est important là-dedans ? L'article nous dit que oui, dans le sens où Git permet d'avoir gratuitement la revue de code, les commentaires dans les fichiers de configuration, de lier les engagements (commit) aux tickets et de gérer les demandes de récupérations d'engagements (pull request). La réponse est donc non, dans le sens où aucune de ces choses n'est spécifique à Git en particulier, les quatre premiers points étant standards à tous les gestionnaires de versions, et le cinquième étant indépendant du gestionnaire de version mais facile à mettre en œuvre dans les gestionnaires distribués de versions.

Ce qui compte donc dans GitOps n'est donc pas Git, mais l'approche déclarative et versionnée, celle qu'on tente de mettre en œuvre depuis plus de vingt ans, et qui est cassée à chaque fois qu'un produit devient à la mode et qui ne sait être configuré qu'en mode impératif (ou pour parler en termes d'affordances trompeuses, par API). Il se trouve que les créateurs sont partis du gestionnaire de source du moment, sans chercher à utiliser ses spécificités, on prend celui utilisé par les développeurs. Et pour Ops… les opérateurs sont des anonymes, tout va bien de ce côté, on peut le rajouter dans n'importe terme :-)

Certains rétorqueront que l'article séminal a été mis à jour, et que si, Git est bien indispensable. Mais ce que cette mise à jour fait vraiment est de montrer en quoi le modèle actuel du Continuous Deployment (ou CD, pas le disque optique) basé sur un enchaînement de scripts impératifs n'est pas réconciliable avec l'approche déclarative, qui elle travaille à deux niveaux : l'expression du changement dans l'exigence, et la mesure de l'écart entre l'exigence et ce qui est en place. L'approche CD traditionnelle (dite du pipeline, ou en Français de la Tech, du pipeline) s'arrête au moment où l'on propage le changement demandé, et ne comporte pas la boucle de rétroaction qui vient après la mesure de l'écart (qui n'est d'ailleurs pas systématiquement faite). On reste donc bien sur les principes de CFEngine, et Git dans l'affaire n'est qu'un accessoire à ces principes, même s'il se trouve techniquement au milieu de cette mise en œuvre particulière.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

mercredi 30 décembre 2020

Affordance trompeuse : API as a Product

En Français de la Tech, l'expression API as a Product est appelée un worst of : elle représente tout ce que l'on souhaite éviter en termes de communication technique.

Pour API c'est assez simple, le terme est apparu à la fin des années 60 pour désigner un contrat d'interface stable et documenté afin de pouvoir utiliser des routines communes. L'acronyme se décompose en Application Program Interface puis a dérivé en Application Programming Interface, soulignant l'importance de la documentation dans l'API. Les deux destinataires d'une API étant le programmeur, pour qu'il puisse écrire du code utilisant les routines communes, et le compilateur qui va vérifier le respect du contrat et écrire le code machine permettant l'appel aux routines. D'autres interfaces existent évidemment, les ABI, SPI, etc… la spécificité des API étant dans le AP, le programmeur d'applications, l'humain qui va être le premier consommateur de cette nourriture.

Pour Product c'est assez simple aussi : en informatique, produit s'oppose directement à service distribué. Le produit c'est ce que l'on installe sur ses propres ressources de calcul, et qu'on utilise sans avoir besoin de la présence d'un tiers (avec le bémol des contrôles de licence à distance).

API as a Product devrait donc être en toute logique… un contrat d'interface permettant de construire un produit ? Un produit permettant de construire et documenter des contrats d'interface ? Que nenni. API as a Product est en fait un raccourci de treating API as a Product c'est-à-dire, pour les fournisseurs de services distribués, de ne pas considérer l'API comme l'interface exposée une fois qu'on a mis en place le service, mais de traiter l'API comme si c'était un produit, en y apportant la même démarche d'analyse, de conception et de commercialisation. Est-ce que cela signifie que l'API devient de ce fait un produit ? Absolument pas, on se situe dans une reformulation de l'approche top-down, selon laquelle on commence par regarder ce que l'on souhaite exposer, pour finir par regarder comment on va le mettre en œuvre, et qui s'oppose à la démarche bottom-up qui est, elle, purement technique.

Jusqu'ici, à part pour l'omission en apparence dérisoire de treating, nous ne sommes pas en présence d'une affordance trompeuse. Pourtant, entre l'apparition du terme fin 2015 et son utilisation aujourd'hui, cette omission s'est avérée fatale : on parle aujourd'hui de boutiques d'API (vu que ce sont des produits), de places de marché d'API (vu que ce sont des produits), de documentation d'API (et plus de la partie documentation de l'API), de rentabilité d'API (vu que ce sont des produits), des données de l'API (vu que l'API n'est plus une interface). Le raccourci de treating API as a Product en API as a Product a fait que le message qui est diffusé est qu'on ne vend plus l'accès à un service distribué, mais à un contrat d'interface, contrat qui par définition n'a qu'une valeur secondaire, celle de faciliter le travail du programmeur pour accéder à ce qui apporte la valeur primaire : la routine mise en commun. C'est dans la perte de ce petit mot treating que l'on est entré dans la tromperie.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

mardi 29 décembre 2020

Affordance trompeuse : REST API, RESTful

Les noms REST API et RESTful invitent au voyage dans le monde des architectures post-Web. Roy Fielding, le seul créateur de REST le dit d'ailleurs explicitement : REST est un style d'architecture qui n'a de sens que dans un système hypermédia distribué. Sans ressources capables de référencer d'autres ressource (hypermédia), sans système qui implique d'avoir de multiples unités de calculs distinctes (distribué), l'architecture retenue pour construire une application ne peut pas suivre un style qui correspond à REST. Et dans ces deux aspects, hypermédia et distribué, étant donné que l'aspect distribué a été traité ad nauseam pendant un demi-siècle, le facteur discriminant est en conséquence l'hypermédia.

L'approche RESTful se concentre sur la mise en place des REST API, et considère que la prise en compte de l'hypermédia est quelque chose d'optionnel, car difficile à mettre en œuvre pour le besoin réel. Comme REST impose l'hypermédia en tant que sujet primaire de réflexion, justement parce que c'est le sujet difficile qui permet de répondre à des besoins auxquels les autres styles d'architecture ne répondent pas, alors on peut en déduire que les termes REST API et RESTful sont représentatifs d'une mouvance NoREST. On trouve un marqueur fort chez les partisans du NoREST : la mise en avant d'un seul format d'échange de données, format qui n'est pas hypermédia, le JSON.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

lundi 28 décembre 2020

Affordance trompeuse : codeur

Le monde de l'informatique s'est créé quand la machine électronique est devenue programmable, quand on pouvait changer son fonctionnement sans passer par une nouvelle étape de fabrication matérielle. Très logiquement, les personnes maîtrisant la création de ces programmes (activité qui nécessite de passer par des étapes d'architecture logicielle, d'analyse, de conception et d'écriture de code) ont été appelées programmers. A contrario, des termes péjoratifs sont apparus pour désigner ceux qui ne méritaient pas cette appellation, comme code grinder (moulin à code), ou code monkey (pisseur de code). La différence entre les deux est que le terme programmer garde dans tous ses usages la notion de travail intellectuel, alors que quand il s'agit de réduire la chose à un simple travail mécanique, ce sont code et coder qui sont utilisés.

Quand, afin de transmettre ses principes, l'informatique pioche son vocabulaire dans les arts mécaniques devenus traditionnels , c'est une bonne idée. Quand les programmeurs réduisent leur travail au codage, ça n'en est plus une.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

samedi 26 décembre 2020

Affordance trompeuse : les frameworks Web MVC

À la fin des années 70, Trygve Reenskaug fait face au problème de la gestion d'un nombre important de données dans une application, et cherche un modèle de programmation qui rende l'application maintenable. On parlera de la maintenabilité dans un autre article, c'est une autre affordance trompeuse. Il arrive après plusieurs itérations et en collaboration au Model View Controller. Rétrospectivement il regrette ce nom de Controller qui n'est pas assez expressif pour le rôle joué.

Le MVC est organisé en une hiérarchie de couples Vue (ce que voit l'utilisateur) - Contrôleur (ce qui reçoit les entrées de l'utilisateur), avec des Modèles sous-jacent (le monde manipulé), la communication entre les Modèles et les Vues se fait dans une approche Observateur / Observé. Si vous enlevez un de ces éléments, vous n'avez plus de MVC. Et pourtant, un article paru sur InfoWorld en 1999 a réussi à populariser le fait que le Model 2 de Sun Microsystems pour Java EE (à l'époque J2EE) était une approche MVC pour le Web : pas de couples Vue - Contrôleur, pas d'organisation hiérarchique ni des Vues ni des Contrôleurs, pas communication Observateur / Observé, pas de support de l'hypermédia, le Model 2 n'était en fait ni MVC ni vraiment Web.

Le MVC se retrouvait réduit à l'état d'une triade vidée de sa substance, un vague Separation of Concerns sans objectif ni raison d'être, et c'est cette vision qui a perduré et a été reprise par la suite dans les frameworks dits Web (Struts, Spring MVC, Django, Symfony, etc…). Cette affordance trompeuse nous suit depuis bien longtemps, voir cet article de 2006 sur la partie dite Web, ou cet article de 2004 où comment cette fausse interprétation du MVC vient polluer la compréhension des vrais frameworks MVC.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

jeudi 24 décembre 2020

Affordance trompeuse : LA DATA

En 1874 Émile Baudot crée un code sur 5 bits pour la télétransmission afin d'être plus efficace que le code Morse. Ce codage permet de représenter les lettres majuscules, les chiffres, la ponctuation… c'est le début du monde de LA DATA. Un point fascinant du monde de LA DATA est ce besoin de REVENIR A DES MAJUSCULES SANS ACCENTS POUR S'EXPRIMER. Le monde de LA DATA EST UN MONDE BRUYANT.

La mode autour de ce vocabulaire est très intéressante, car elle montre deux points de vue différents entre la francophonie et les outres (outre-Manche, outre-Atlantique). L'idée principale convoyée par les dénominations anglaises est toujours celle du calcul : dans computing science, le premier mot a la même racine latine que le mot français computer, c'est-à-dire computare, calculer. Dans software engineering, le premier mot a été créé en opposition au hardware, au matériel : on continue de parler de l'outil, toujours pas des données.

En vocabulaire anglais, il est donc nécessaire de remettre en avant la donnée, ou comme on dit en Français de la Tech, de remettre en avant LA DATA. En vocabulaire français par contre, on va parler d'informatique, et ce depuis le début de la diffusion des ordinateurs dans les années 60 (qui ne sont que des calculateurs pour le coup), c'est-à-dire de la science du traitement rationnel, notamment par machines automatiques, de l'information considérée comme le support des connaissances humaines et des communications dans les domaines technique, économique et social.

Cela fait donc plus d'un demi-siècle qu'en vocabulaire français on a considéré que LA DATA était la partie fondamentale de notre activité, et qu'en deuxième position arrivait la problématique du calcul automatisé. L'utilisation sans réserve de LA DATA dans nos contrées est donc un indicateur fort de l'inculture informatique de nos entreprises, en particulier dans la French Tech.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Affordance trompeuse : JSON

JSON est un format de texte bien connu, et format privilégié des amateurs de l'approche NoREST. Ce format, très simple, est défini dans la RFC 8259 de l'IETF ou encore ECMA-404 de l'ECMA, qui spécifie que l'acronyme signifie "JavaScript Object Notation". On pourrait donc s'attendre à ce qu'on puisse décrire en JSON un objet au sens JavaScript, à savoir quelque chose avec un état et un comportement, des propriétés et des méthodes. Juste après, la spécification précise que JSON est un format d'échange de données, on comprend donc que la partie "comportement" ne fera pas partie de JSON. On pourrait du coup s'attendre à ce que les types de données scalaires JavaScript standards soient supportés dans JSON. Ce n'est pourtant pas le cas, seuls les nombres et les chaînes de caractères sont décrits et, par le tour de passe-passe d'utilisation de mots-clefs, on ajoute les booléens. Au final, le JavaScript dans JSON est l'équivalent de Git dans GitOps : un tube néon qui va mettre en valeur le nom.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Affordance et programmeurs, une histoire de noms

Affordance est un néologisme créé par le psychologue James J. Gibson dans les années 60 pour désigner ce que l'environnement a à nous offrir. A la fin des années 80, ce terme prend un sens complémentaire, avec la notion de perception de cette offre. Par exemple avec l'iPhone, Apple a introduit la possibilité de zoomer avec un mouvement de pincement effectué digitalement (c'est-à-dire avec les doigts) sur l'écran : dans la désignation des années 60, cette possibilité est une affordance, dans celle des années 80, c'est une affordance cachée. On parlait aussi de fausses affordances, comme par exemple quand un bouton est présent mais rien n'est câblé derrière. Dans les années 2010, une nouvelle utilisation du terme est apparue, au singulier cette fois, où l'affordance de quelque chose est sa qualité à proposer des affordances visibles.

Cette notion est clef dans les interactions homme-machine, spécialement pendant la phase de découverte de l'interface, de la surface qui sépare l'humain de l'informatique. Une fois l'interface connue, assimilée, la personne travaille par raccourcis, par accélérateurs et ce besoin d'affordances visibles diminue. On pourrait donc penser que ce concept d'affordance va être clef pour les informaticiens, qui vont avoir à cœur de le mettre en pratique dans l'organisation de leur travail. C'est un peu le cas, mais avec une subtilité : les informaticiens aiment aller au-delà de l'affordance, ni affordance visible, ni affordance cachée, ni fausse affordance, mais avec l'affordance trompeuse, celle qui donne à croire qu'on a une certaine affordance, mais qui propose en fait tout autre chose.

Ceci se pratique essentiellement à travers la démarche de dénomination, élément essentiel de toute communication. Certains diront que le vocabulaire est nécessairement mouvant dans le temps, et que le nom des choses est ce que la masse en fait. Il n'en reste pas moins que ceux qui connaissent le sens d'origine du vocabulaire ne peuvent que se sentir attaqués et trahis, dans une démarche certes victimaire, mais pour laquelle on peut ressentir une certaine empathie en toute bienveillance. Et passé ce point de détail, dans toute démarche scientifique, et l'informatique aspire à s'en approcher, il est important de ne pas effacer le passé en se servant du vocabulaire comme d'un palimpseste.


Cet article sert de point d'entrée à la série "Affordances trompeuses", il sera mis à jour au fur et à mesure avec les différentes entrées.

  1. JSON
  2. LA DATA
  3. Les frameworks Web MVC
  4. Codeur
  5. REST API, RESTful
  6. API as a Product
  7. GitOps
  8. Dette technique
  9. La qualité
  10. Les bonnes pratiques
  11. La refactorisation
  12. Le cache
  13. Le data center
  14. API