« bon code »

id : 20200830153041
dernière édition :
type : programmation
mots-clés : lecture code, Samuel Goyet

Un code « propre » est un code que l’on a envie de lire, que l’on prend plaisir à comprendre et qui nous donne envie de poursuivre l’effort dans son inscription et sa conception en vue de sa maintenance 🔗 (enjeux économique, politiques). C’est une culture professionnelle pour aborder le code comme un document de travail et non plus seulement une interface[^1] (p.465), des points de vue

  • socio-sémiotique : aborder le code selon la variété de la culture métier des individus
  • techno-sémiotique : « le code en tant qu’il fixe les conditions de possibilités d’écriture de l’utilisateur »[^1] (p.465)

Un bon programmeur est bienveillant.

Le code n’est pas neutre et structure la rencontre entre les humains et les machines. Ils convient de soigner cette présentation. Pour cela, on considère les critères suivants :

  • indenté, espacé… profitant de toutes les qualités typographiques fondamentales 🔗
  • réflexion sur le sens du nom de variables 🔗
  • commenté 🔗
  • utilisation de modèles 🔗, paradigmes 🔗 et autres normes qui permettent de saisir les intuitivement les intentions
  • efficace : minimum d’instructions et de mémoire utilisé pour une série de processus donnée

« Nous pouvons concevoir des abstractions profondes qui permettent aux utilisateurs d'exploiter de petites API simples pour accéder à des comportements puissants et utiles. […] Nous pouvons être gentils avec ceux qui doivent lire notre code en étant aussi clairs, aussi simples et aussi explicites que possible. Nous pouvons donner aux types et aux fonctions des noms significatifs, qui ont un sens dans leur contexte, et laisser les utilisateurs créer leurs propres programmes en utilisant nos abstractions dans des combinaisons simples et logiques. Nous pouvons éliminer les barrières cognitives et les ralentisseurs en respectant les conventions, en mettant en œuvre des interfaces standard et en faisant ce qui est évident de la manière la plus évidente »[^2]

Nous connaissons trois maximes en programmation. Elle visent à produire un code plus simple.

  • DRY : Don't Repeat Yourself : Utiliser au maximum des fonctions (même très simples) pour stocker le code exécuté à différents endroits.
  • KISS : Keep it simple, stupid : Écrire le code le plus simple possible.
  • NIH : Not invented Here : Ne pas refaire soi-même ce qui est offert ailleurs.

[^1]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^2]: John Arundel, The Tao of Go

abstraction

id : 20210412165919
dernière édition :
type : architecture

L’abstraction est un exercice d’analyse concistant à appliquer des modèles 🔗 pour simplifier des entités : objets, informations, procédures… Plus un modèle 🔗 englobe d’entités, plus il est abstrait.

L’abstraction est une posture intellectuelle face à la complexité 🔗. On lui oppose des modèles 🔗 issus d’un savoir-faire, d’une culture, d’un envrionnement…

« C’est une simplification, en présence de l’objet concret infiniment complexe et perpétuellement changeant, simplification qui nous est imposée, soit par les nécessités de l’action, soit par les exigences de l’entendement, et qui consiste à considérer un élément de l’objet comme isolé, alors que rien n'est isolable, et comme constant alors que rien n'est au repos. »[^1]

Par opposition, concrétiser une entité consiste à revenir à sa forme naturelle et ultra-complète.

[^1]: CNRTL, Abstraction

AJAX protocole de requêtes asynchrones

id : 20200704100343
dernière édition :
type : programmation
mots-clés : technique

🔗 requête 🔗 langage de programmation Javascript

L’AJAX (asynchronous JavaScript and XML) recours à la class JavaScript « XMLHttpRequest » incluse dans les navigateurs modernes. Elle permet d’adresser des requêtes HTTP afin d’obtenir des données au format XML, JSON, HTML ou plein texte, comme si l’utilisateur s’était lui-même rendu à l’adresse.

Le traitement se fait désormais principalement en JSON étant donné qu’il s’agit d’un objet JavaScript. Il faudrait en réalité plutôt parle de AJAJ (asynchronous JavaScript and JSON).

L’avantage est qu’il est possible d’obtenir des données (« en arrière-plan ») sans recharger la page : c’est asynchrone car c’est un chargement de données décalé avec celui de la page.

🔗 comportement logiciel

Avec JavaScript on peut ensuite modifier agit sur le code source de la page, par exemple pour afficher un retour (callback) suite à un envoi de formulaire. Cette action n’étant pas synchronisée avec une interaction utilisateur (délais de requête), on parle d’une opération asynchrone.

Inscription

JavaScript vanilla

Nouvelle inscription

fetch('data.json').then(function(response) {
    // Chargement de données...
    response.text().then(function(text) {
        // Traitement des données...
        var data = JSON.parse(text);
    });
});

🔗 callback, principe de programmation asynchrone

Ancienne inscription

var req = new XMLHttpRequest();
req.open("GET", "./controller/function.php");
req.addEventListener("load", function () {
    if (req.status >= 200 && req.status < 400) {
        fxCallback(req.responseText);
    } else {
        console.error(req.status + " " + req.statusText + " " + url);
    }
});
req.addEventListener("error", function () {
    console.error("Erreur réseau à l'URL " + url);
});
req.send();

JQuery

$.ajax({
    url: "./controller/mail.php",
    type: 'POST',
    data: formulaire.serialize(),
    dataType: 'JSON',
    success: function (JSON, statut) {

        if (JSON.isOk) {formulaire.trigger('reset');}
        formulaire.append('<p>' + JSON.consolMsg + '</p>');
    },
    error: function (resultat, statut, erreur) {
        console.log(resultat);
        console.log(erreur);
    }
});

annotation de la documentation logicielle

id : 20210630161233
dernière édition :
type : documentation

L’annotation de la documentation consiste à rassembler des données diverses autour de son utilisation par différents moyens :

Des trackers permettent de savoir quelles sont les pages les plus visitées, combien de temps, avec quelle poursuite de navigation. Là on peut retrouver des parcours de lecture plus ou moins linéaires. On peut repérer des pages où les utilisateurs arrêtent leur navigation en masse, peut-être parce qu’ils on la solution, peut-être parce qu’ils manquent d’alternatives pour la poursuite de leur lecture.

« Mettez l’accent sur les informations qui sont lues fréquemment par de nombreux utilisateurs. Réduisez le nombre d’étapes nécessaires pour atteindre ces informations. »[^1]

On peut aussi proposer de compléter des formulaires 🔗 de satisfaction (« Avez-vous réussi à trouver une solution à votre problème ?) ou même de laisser un commentaire sur la page pour informer les autres utilisateurs (suggestions d’amélioration, compléments d’informations).

« avec de nombreux systèmes hypertexte, le lecteur est l’auteur, et les lecteurs sont encouragés à annoter, restructurer et même réécrire de nombreux documents de ce type »[^1] (p.76)

Augmenter la documentation

Dans un contexte hypertexte 🔗 on peut compter sur les autres sites web pour relier les pages et informations de notre propre documentation. Pour cela, les différentes sections (pages, parties, paragraphes) doivent être identifiés afin qu’un utilisateur puisse se rendre d’un point précis à l’autre.

D’autres système de participation peuvent graviter autour de la documentation pour permettre aux utilisateurs de la modifier :

  • les wikis 🔗 pour permettre aux utilisateurs d’écrire et réécrire les informations et leurs liens ;
  • les forums de discussion permettent aux utilisateurs de préparer des narrations alternatives, de lier d’autres ressources et de compléter le tout avec leur propore expérience. Ce sont des plateforme utiles au sein de la communauté.

[^1]: Wiliam Horton, Designing & writting online documentation, 1990

API de Electron

id : 20210829183842
dernière édition :
type : architecture

L’interface de programmation 🔗 des applications Electron 🔗 permet aux développeurs de manipuler à la fois l’interface (front end) et le processus (back end).

strate environnement de programmation langages
interface Chromium JavaScript, HTML et CSS
processus NodeJS CommonJS

Ces deux strates sont isolées. Les contextes (espace de nom 🔗, espace fonctionnel) sont séparés. Ainsi on considère trois milieux :

  • main.js (et ses imports) : accès à tous les modules et aux extensions ;
  • preload.js : accès aux processus de Electron et aux éléments de la page (une fois chargée) ;
  • render.js : accès à la page.

Liaison

Ces trois milieux sont reliés dans un environnement de développement hypertextuel 🔗. D’abord main.js fait appel à preload.js et au fichier source de la page (source.html) qui lui-même fait appel à render.js.

const window = newBrowserWindow (
    width: 1600,
    height: 1000,
    webPreferences: {
        contextIsolation: true,
        preload: path.join(__dirname,'preload.js')
    },
    title: 'Titre de la page'
);

window.loadFile(path.join(__dirname, 'source.html'));
<head>
    <link rel="stylesheet" href="style.css">
</head>

<body>
    <script src="render.js"></script>
</body>

Les contextes étant isolés, il est nécessaire d’utiliser des protocoles de communication pour passer des données entre les contextes.

// main.js
ipcMain.on("askUpdate", (event, dataFromRender) => {
    const result = updateFromMain(data.id);
    window.webContents.send("getUpdate", result);
});

// preload.js
contextBridge.exposeInMainWorld(
    "api", {
        askUpdate: (dataFromRender) => ipcRenderer.send('askUpdate', dataFromRender),
        getUpdate: () => ipcRenderer.on('getUpdate', (event, result) => {
            return updateRender(result);
        })
    }
);

// render.js
window.api.askUpdate(dataFromRender);
window.api.getUpdate(resultFromMain);

Les contextes étant isolés, il n’est possible de faire appel aux données de main.js depuis render.js qu’en disposant un pont contextuel via preload.js.

API, interface de programmation

id : 20200701221037
dernière édition :
type : architecture
mots-clés : Anthony Masure, Samuel Goyet, politique, médiation

🔗 interface

Une API (Application Programming Interface) permet de mettre en relation des programmes[^2] de manière structurée (modulaire 🔗). Il s’agit en général d’échanger des données 🔗 entre deux parties, de faire communiquer des bases selon les principes de l’application 🔗 : l’API standardise un traitement et tend à uniformiser les programmes et interfaces.

« ensemble normalisé de classes, de méthodes, de fonctions et de constantes qui sert de façade par laquelle un logiciel offre des services à d’autres logiciels »[^1]

« Une API permet à un développeur – une personne qui écrit des programmes informatiques – d’accéder à des jeux de données ou à des blocs de code informatique préécrits pour remplir une certaine fonction »[^3] (p.36)

🔗 structures de contrôle

L’utilisation des API dépend de la documentation 🔗 qui les accompagne. Elle permet de définir notamment « ses usages possibles, la syntaxe à respecter, les formats et type de données disponibles »[^3].

Usage

Ainsi, les API sont omniprésentes dans l’univers composite du Web. On retrouve des API pour toutes sortes de services en ligne :

  • intégration (via un code HTML à copier coller) d’un simple affichage, comme un bouton like de Facebook ;
  • intégration d’une carte (Google Maps ou Openstreet Map) en intégrant l’élément HTML et en soumettant des requêtes AJAX 🔗 pour l’actualiser ;
  • récupération massive de sets de données auprès d’une base (Twitter) ;
  • pairement en ligne via des formulaires validés à l’aide de clés/jeton d’authentification (token) par un service distant qui statut sur la requête.

Autant de sorties ou d’entrées par lesquelles il est possible de faire transiter (via des tuyaux, pipe) des données.

« Historiquement, les API web se sont développées à partir des années 2000, d’abord autour d’Ebay qui publie son API en 2000, puis Amazon en 2002 […] Google Maps en 2005 […] celle de Twitter […] et de Facebook, toutes deux en 2006 »[^3] (p.40-41)

Risques

« les API ne peuvent justement pas être réduites à leur fonction technique. Elles ont un rôle économique, culturel, politique… Elles sont éminemment ‹ composites ›. Ce sont des objets techniques, qui font partie de nos lectures quotidiennes sans que l’ont ait à s’interroger plus en avant sur cette part technique »[^3] (p.40)

« quatre grands risques découlant d’un usage d’une API: la pression financière, l’instabilité de son fonctionnement, l’homogénéisation des interfaces, et son invisibilité structurelle »[^2]

  • économique : « les API font partie d’un mouvement contemporain de valorisation de la ‹ donnée › comme vecteur de richesse […] si les données sont un enjeu économique et symbolique important, alors les moyens d’accès à ces données deviennent des points de passage névralgiques »[^3] (p.41)
  • culturel : les API « permettent la création de ‹ petites formes › participent à un mouvement de transformation, d’hybridation d’objets culturels fondamentaux par le biais du numérique »[^3] comme avec les carte Google Maps, « lieux où l’hybridation se fait jour, entre la culture informatique de la programmation et la culture lettrée »[^3] (p.42), entre l’outillage technique et la création du sens par l’outillage technique.
  • politique :
    • « enjeux politiques de monstration ou d’invisibilisation »[^3] (p.57)
    • « Grâce à leurs API, Amazon ou Google créent un ‹ écosystème › de développeurs, qui dépendent des données de ces plateformes pour écrire leurs propres logiciels, mais qui en retour bénéficient de moyens d’accès facilités à ces données (grâce à l’API) et peuvent donc les utiliser à leurs propres fins »[^3] (p.41)

Médiation opaque

Une API est une médiatrice de la donnée dans le sens où elle est un péage permettant de contrôler le flux de données pouvant sortir, mais elle en cache aussi la source. Le fonctionnement de l’API même est difficile à appréhender, voire opaque (boîte noire). On sait capter et traiter les données grâce à la documentation, mais on ne sait pas d’où elle viennent, ni comment elles sont rassemblées, ni comment elles sont envoyées. Souvent, le flux de données reçu (volume d’usage) est volontairement limité par l’expéditeur.

« Le conducteur [développeur] ne voit qu’une interface composée d’un volant, de pédales (accélérateur, embrayage, frein), de manettes (clignotants, phares, boîte de vitesse) et de boutons (avertisseur, anti-brouillard, klaxon, etc.) »[^2]

C’est un frein à la rétro-ingénierie, mais aussi un moyen de développer plus rapidement des systèmes complexe. On peut faire abstraction 🔗 du fonctionnement et des moyens pour se concentrer sur la programmation d’un outil.

« la facilité d’accès aux API permet au développeur de ne pas se soucier de la façon dont fonctionne effectivement l’application distante […] L’API éloigne donc le programmeur d’un code trop complexe et fait écran avec les fonctions des langages de programmation dits standardisés »[^2]

Contrôle du flux

Utiliser une API revient à céder le contrôle du flux des données, par nature instable. Il peut être déplacé, interrompu, limité (quotas), modifié (structure et/ou contenu) et son contenu est soumis aux règles d’une base externe, celle de son propriétaire. Plutôt que de parler d’intégration de ces données sur un support, il faudrait parler d’ancrage, le contenu n’était pas solidaire de l’interface, mais récupéré.

Pour la gestion des accès (sécurité, confiance, péage) on compte sur des clés/jetons d’authentification (token) uniques. Elles sont chiffrées 🔗 et permettent accordent les échanges entre trois entités : l’utilisateur, le développeur et le pourvoyeur. En général, le deuxième met en place le pont entre les deux autres. Sa position de médiateur est authentifiée (contrôlée) via une clé privée. Il va transmettre une clé publique (envoyée par le pourvoyeur) à l’utilisateur. Ce dernier va l’utiliser pour utiliser l’API.

Exemple de clé : a4db08b7-5729-4ba9-8c08-f2df493465a1

Pour prévenir une coupure de l’API, on peut mettre en place un système de cache permettant de garder dans une autre base (sauvegarde) les données récoltées à la source. Cela reste une pratique pouvant être limitée par le propriétaire des données.

[^1]: Wikipédia, Interface de programmation [^2]: Anthony Masure, Le design des programmes, 2014 [^3]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

application

id : 20200909183033
dernière édition :
type : architecture
mots-clés : Julien Dehut, Anthony Masure, politique

Par rapport à un logiciel, une application (« app ») est destinée à un usage circonscrit. Elle a l’avantage d’être conçue sur une chaîne de production entièrement contrôlée par les fabricants. Ils ont conçu un environnement complet pour contrôler l’utilisation des usagers, mais aussi le travail des concepteurs. Même les designers et développeurs, les professionnels du numérique, sont influencés dans leur métier dans ce sens. On trouve des applications sur les smartphones, mais aussi les ordinateurs (Chrome OS est la plateforme la plus fertile, mais on en trouve aussi sur Windows et Mac OS) et sur le Web (plateformes fonctionnant sur des API 🔗).

L’application est un outil de l’esclavage moderne, de l’aliénation à la production (gratuite et/ou détournée, cachée) de données.

🔗 digital labor

«  La notion d’application est dénoncée depuis 1971 par Ted Nelson qui y voit là une source d’asservissement pour le public »[^1]

Les utilisateurs et les designers s’adaptent à ces interface (aux usages qu’elles engendrent) au fil des mises à jour. Nous sommes invités à servir toujours plus, toujours plus efficacement.

🔗 théorie du nudge

« l’actuelle ‹ génération de logiciels › des terminaux mobiles prend le nom d’‹ applications ›, distinction qu’il y a lieu d’interroger »[^2]

Logiciel // application

L’informatique a changé. Il est devenu portable, plus facile d'utilisation et plus facile à programmer. Les applications sont le résultat de cette transformation (facilitation et accélération). Les développeurs et les designers sont au cœur de cette logique. Les GAFAM donnent généreusement des guides aux professionnels (pour faciliter leur travail, mais aussi l’influencer) pour que jamais on ne trouve une interface qu'ils n'est pas optimisé pour leur récolte.

Ainsi, l’application est un logiciel normé dont on a limité l’environnement logiciel 🔗 et interactif :

  • guidelines pour les designers
  • Software Development Kit (SDK) développeurs

Les applications permettent aux utilisateurs d’effectuer des tâches spécialisées (ex : Word → traitement de texte) quand les logiciels peuvent avoir une portée très générique (ex : système d’exploitation).

Le ressentis d’utilisation d’une application est fermé à la notion de programmes tant son fonctionnement, ses entrées et sorties, son API, sont opaques (boîte noire, cryptotechnique). Le perfectionnement des techniques informatiques mène inéluctablement à l’effacement de ces techniques. Les utilisateurs et développeurs cherchent des solutions « tout intégrées », des interfaces qu’ils ne veulent pas comprendre, mais simplement utiliser dès lors qu’elles sont simple, efficace et sécurisées.

🔗 rapport aux objets techniques

À l’opposé, nous trouvons les logiciels LOS 🔗, dont le code source (et donc les programmes) est visible par tous et peut être améliorer par une communauté plus ou moins restreinte.

Développeurs

Ces modalités ont un effet direct sur le développement et la maintenance de ces logiciels. Ils sont soumis à différentes plateformes (constructeur du terminal + système d’exploitation + marché d’applications), à leurs changements, et leur chantage. Les constructeurs n’hésitent pas à limiter l’usage de l’appareil en limitant ses mises à jour tandis que les applications doivent elles suivre l’évolution du système d’exploitation. Les développeurs sont contraints de respecter les ambitions économiques des différents partis.

« Citons, en plus des limitations déjà présentes sur l’App Store iPhone et iPad : […] pas de mise à jour payante depuis un ancien logiciel […] ; pas de code fonctionnant en arrière-plan une fois l’application fermée […] ; pas d’accès aux code de bas niveau […] »[^2]

En échange de cela, le développement de ces logiciels est très rapide, facilité par des outils sur mesure pour les porter d’un marché d’application à un autre. Plus le matériel est normé (l’iPhone est un exemple typique), plus il est facile de généraliser la compatibilité de l’application à des centaines d’appareils parfois très différents (issus du même écosystème). La mise sur un marché aussi fermé qu’un store d’application permet à des logiciels de se démarquer rapidement, autrement que dans la jungle du Web. Ils y sont mis en concurrence par un système de notation, commentaire. Les utilisateurs peuvent rapidement télécharger leur solution et la garder à jour automatiquement.

Utilisateurs

Les utilisateurs perdent largement le contrôle des appareils sur lesquels ils installent des applications. Le système d’exploitation de ces appareils sont largement bridés et l’API ne tolère aucun écart, à moins de la casser (jailbreak des iPhone, qui fait perdre la garantie de l’appareil). Les interfaces sont semblablent d’une application à une autre (suivant les guidelines du système d’exploitation) forçant les utilisateurs à se conformer (par le design) à une unique manière d’utiliser leur terminal, de penser leur navigation. Ils sont enfin largement soumis à la récolte de données (en amont ou en aval des applications elles-mêmes) et au marché de la publicité. Les applications sont les supports du travail gratuit sur le Web 🔗 ; c’est le réel objectif des marchés d’applications.

En échange de cela, l’utilisateur peut profiter d’un grand nombre d’applications qui le suivront tout au long de la vie de son appareil et d’un appareil à l’autre. Il pourra profiter d’un écosystème qui lui permet d’aménager (dans une certaine mesure) un espace de travail. Ce écosystème (entre les applications et avec l’appareil) est aussi sécurisant et protège l’utilisateur d’installations frauduleuses qui pourrait abîmer son appareil (ou voler ses données, le faire payer sans que le marché d’application ne touche sa commission).

[^1]: Julien Dehut, En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation, 2018 [^2]: Anthony Masure, Le design des programmes, 2014

arborescence

id : 20210915103658
dernière édition :
type : architecture

Une arborescence est un graphe 🔗 hierarchique. Il comporte une sommet particulier appelé racine, soit le nœud originel. La racine est parente (prévaut sur) de tout les autres nœuds alors dits enfants. Tous les nœuds partageant un même parent direct (sans parent subalterne) sont frères.

On peut représenter une arborscence comme ci-dessous. chat et guépard sont frères, enfants de animaux/, vertébrés/ et mamifères/. vertébrés/ est parent de gallinacé/, poules et pintades.

animaux/
└── vertébrés/
    ├── mamifères/
    │   └── félins/
    │       ├── chat
    │       └── guépard
    └── gallinacé/
        ├── poules
        └── pintades

Fonctions

La fonction hiérarchique implique

  • héritage : un parent communique ses attributs à tout ses enfants ;
  • encapsulation 🔗. les frères ne partagent pas leur attributs particuliers dont seul leurs enfants hériteront.

architecte logiciel

id : 20210602103346
dernière édition :
type : undefined
mots-clés : projet

🔗 architecture logicielle

« Si l’architecture est ce qui est important, alors l’architecte est la personne (ou les personnes) qui se préoccupe(nt) de ce qui est important »[^1] (p.3)

Martin Fowler[^1] distingue deux types d’architectes, garants de l’« intégrité conceptuelle » :

  • l’architectus reloadus (comme celui de Matrix Reloaded) : personnalité centrale, « esprit unique » conservant toutes les connaissances relatives à l’architecture et du même coup l’investigateur de toutes les décisions pour son équipe ;
  • l’architectus oryzus : collaborateur intensif, c’est un médiateur des connaissances relatives à l’architecture donnant à chaque équipier la capacité d’aborder des problèmes de plus en plus complexes 🔗.

« En améliorant les capacités de l’équipe de développement, l’architecte dispose d’un levier beaucoup plus important que s’il était le seul décideur et courait ainsi le risque d’être un goulot d’étranglement architectural. Cela conduit à la règle empirique satisfaisante selon laquelle la valeur d’un architecte est inversement proportionnelle au nombre de décisions qu’il ou elle prend »[^1] (p.3)

Bill Curtis[^2] (p.167) rapporte que « La productivité des ingénieurs logiciels est influencée par l’étendue de leur compréhension du système qu’ils développent ou modifient », soit leur compréhension de l’architecture du logiciel 🔗 telle qu’elle a été présentée au sein de l’équipe, notamment par le biais de la documentation logicielle 🔗 : « La qualité de la documentation disponible déterminera en partie la rapidité et l’exhaustivité de la compréhension d’un système par les ingénieurs logiciels ». La mise en place de cette même documentation peut être motivée par la peur de prendre ses architectes en cours de projet[^3] (p.125).

[^1]: Martin Fowler, Who Needs an Architect?, 2003 [^2]: Bill Curtis, Experimental evaluation of software documentation formats, 1989 [^3]: Alistair Cockburn, Agile Software Development, 2002

Architecture de von Neumann

id : 20210728110654
dernière édition :
type : undefined

L’architecture de John von Neumann est un modèle pour les machines appelées ordinateurs à programmes élaboré en 1945.

John Backus[^2] (p.615) présente les trois composants d’une telle machine :

  • unité centrale de traitement : séquençage des opérations ;
  • magasin : données et instructions de traitement des programmes ;
  • tube de connexion (« goulot d’étranglement »).

« La tâche d’un programme est de modifier le contenu du magasin d’une manière importante ; si l’on considère que cette tâche doit être accomplie entièrement en pompant des mots uniques dans les deux sens à travers le goulot de von Neumann, la raison de son nom devient claire. Ironiquement, une grande partie du trafic dans le goulot d’étranglement n’est pas constituée de données utiles mais simplement de noms de données, ainsi que d’opérations et de données utilisées uniquement pour calculer ces noms »[^2] (p.615)


Elle permet de distinguer 4 composants[^1] :

  • unité arithmétique et logique :  ;
  • unité de contrôle : séquençage des opérations ;
  • mémoire : données et instructions de traitement des programmes ;
  • dispositifs d’entrée-sortie : communication avec les périphériques.

[^1]: Wikipédia, Architecture de von Neumann [^2]: John Backus, Can Programming Be Liberated from the von Neumann Style?, 1977

architecture logiciel MVC

id : 20200704172042
dernière édition :
type : architecture

L’architecture logicielle MVC se compose en trois parties en relation selon le schéma ci-dessous :

  • Model : gestion des flux de données
  • View : génération de l’affichage, de l’interface 🔗
  • Controller : gestion des requêtes 🔗 utilisateur et de sa session

C’est un dispositif adapté à l’architecture trois tiers, elle-même conçue pour faire communiquer le client, l’application et la base de données. Elle prescrit trois couches : présentation, traitement et accès aux données.

🔗 client serveur

graph TD
	Model[Model]
	View[View]
	Controller[Controller]
	
	client((client))
	
	client -->|1 requête| Controller
	Controller  -->|2 demande données| Model
	Model  -->|3 obtention données| Controller
	Controller  -->|4 transmition données| View
	View -->|5 affichage| client

Cette architecture permet d’éditer les fonctionnalités d’une couche, sans induire de changement dans les autres. On évite ainsi les effets de bord 🔗.

Mise en place

Cette architecture se matérialise directement dans l’arborescence de fichier comme ci-dessous :

.
├── index.html
└── core/
    ├── model/
    │   └── user.php
    ├── view/
    │   └── connexion.php
    └── controller/
        └── authentification.php

Grâce à des conditionnels (inspection des requêtes et de la session du client), on va réaliser différentes inclusions de code pour exécuter les différentes opérations.

Technologies

Entre la View et le Controller on va généralement mettre en place un pipe AJAX 🔗 pour éviter les rechargements de pages et ainsi donné l’illusion d’une application web avec la fluidité d’affichage que cela implique.

Les models sont en général inscrits avec le paradigme de la programmation orientée objet 🔗 pour sécuriser les appels à la base de données.

De nombreux framework 🔗 mettent à disposition une architecture MVC comme Symfony, Laravel ou AngularJs.

architecture logicielle

id : 20210531145255
dernière édition :
type : processus

Martin Fowler parle de l’architecture logicielle comme d’un « devoir moral »[^2] pour les développeurs. Nous devons être de « bons artisans »[^2] (même si la raison économique gagne). L’architecture logicielle n’apporte rien aux utilisateurs, clients, c’est une « qualité interne »[^2] du projet. Après un temps dédié (prise d’élan), elle permet à l’équipe d’accélérer dans l’implémentation 🔗 de fonctionnalités en repoussant la dette technique 🔗.

Martin Fowler cite différentes définitions de l’architecture logicielle. Elle est

  • « le concept de plus haut niveau d’un système dans son environnement »[^1] (p.2), soit la plus haute abstraction 🔗 du logiciel, son interface globale, elle-même étant découpé en plus petites interfaces de compréhension ;
  • « l’organisation fondamentale du système, incarné par ses composants, leurs relations, leur environnement ainsi que toutes les règles de direction qui s’appliquent à son design et son évolution »[^2] ;
  • « L’architecture, ce sont les décisions que l’on aimerait pouvoir prendre au début d’un projet »[^1] (p.3) ainsi que l’on aimerait poser les fondations pour un ouvrage réaliser linéairement, sans friction ; finalement on se retrouve tout de même à concevoir une architecture modulaire 🔗 pour pouvoir prévoir les modifications imprévisibles, c’est ainsi qu’on augmente la complexité du logiciel 🔗 ;
  • « les notions que les experts du système partagent »[^2], « une compréhension commune de la conception d’un système »[^1] (p.2), deux définitions intéressantes proposant de considérer l’architecture sous l’angle de la collaboration.

Ainsi, l’environnement de développement 🔗 est une notion prépondérante dans l’appréhension d’une architecture. Elle est un objet social plus qu’une donnée matérielle.

Objet social

« Oublions les développeurs qui ne comprennent que leur petit morceau. L’architecture est le concept de plus haut niveau des développeurs experts »[^1] (p.2)

L’architecture du logiciel est ce que les personnes qui le maintiennent en ont compris. Elle est un objet social complexe 🔗 (jargon, relations, confusions…) car elle se base sur le travail d’humains, mais aussi sur leur compréhension de cet ouvrage. C’est cette analyse qui permet aux personnes de travailler sur le logiciel ; ces éléments que tous doivent avoir en tête pour concevoir et implémenter ; c’est sa compréhension qu’il faut nourrir tout au long du développement.

« Cette compréhension [de l’architecture] comprend la façon dont le système est divisé en composants et la façon dont les composants interagissent par le biais d’interfaces. Ces composants sont généralement composés de composants plus petits, mais l’architecture ne comprend que les composants et les interfaces qui sont compris par tous les développeurs »[^1] (p.3)

En tant que fondation sociale et technique, l’architecture est difficile à modifier. Pour comprendre l’architecture, on peut se demander ce qu’il est difficile de changer dans le projet. Par exemple, un langage de programmation 🔗 est difficile à remplacer ; d’un point de vie technique il faut modifier une bonne partie de l’environnement de développement pour cela ; d’un point de vue discursif, il faut adapter les paradigmes utilisés et que tous les comprennent.

Faiblesse des représentations

L’architecture n’est pas une suite de documents. Martin Fowler[^2] critique l’idée de considérer l’architecture à travers une documentation, car ces modélisations de l’architecture logicielle 🔗 sont en général mal conçues et ne permettent pas de saisir les connaissances qui doivent être partagées, notamment au sein des communautés de développement 🔗.

[^1]: Martin Fowler, Who Needs an Architect?, 2003 [^2]: Martin Fowler, Making Architecture Matter, 2015

architexte

id : 20210115090700
dernière édition :
type : inscription
mots-clés : Yves Jeanneret, Emmanuel Souchier, Cléo Collomb, Samuel Goyet, politique, médiation

Les architextes sont des « couches de textes »[^3], des textes permettant l’accès à d’autres textes et finalement aux écrits d’écran[^2]. Ce sont des textes (« écriture-calcul »[^4]) capables de récupérer et formater d’autres textes (« écriture-texte »[^4]) pour enfin les afficher. S’ils sont tous écrits et intelligibles par l’humain, ces textes sont de différentes natures. On oppose ainsi l’écriture-texte pour les humains et l’écriture-calcul pour les machines[^4].

🔗 inscription computationnelle

« Nous nommons architextes (de archè, origine et commandement), les outils qui permettent l’existence de l’écrit à l’écran et qui, non contents de représenter la structure du texte, en commandent l’exécution et la réalisation »[^1]

« Un traitement de texte, un champ de recherche Google, un logiciel de montage vidéo, une API sont des architextes : ce sont des outils qui permettent d’écrire grâce à un ordinateur. Ces outils ont deux particularités : ce sont des ‹ outils d’écriture écrits ›, ils permettent donc l’écriture en la formatant dans le même temps ; ils sont propre à l’informatique en ceci que cette technique d’écriture est fondée sur une rupture sémiotique et sémantique. C’est cette rupture qui nécessite des outils de conversion – les architextes – entre le niveau de l’inscription (la matérialité du disque dur ou de tout support de mémoire) et celui de l’affichage (l’écran, l’interface) »[^5]

Médiation

L’écrit d’écran « reconnaît la rupture opérée par l’informatique entre le support et le signe, entre le calculé et le perceptible »[^3] et les architextes opèrent la médiation entre le signe et son support, reliés par la computation, le calcul.

« Le texte naît de l’architexte qui en balise l’écriture »[^6] (p.103)

Cette médiation n’est pas une interaction entre l’humain et la machine 🔗, mais entre un humain et un autre humain par l’intermédiaire d’une machine. Le premier a écrit un texte (code) pour permettre au second de lire d’autres textes.

« Si quelque chose se passe à l’écran, ce n’est pas en raison d’une quelconque interactivité [entre l’humain et la machine], mais parce que des architextes ont en amont rendu possible la saisie d’un comportement humain comme un geste d’écriture ayant pour effet d’afficher un nouveau texte »[^3]

Contrôle

Les architextes sont aussi un moyen de contrôle du texte par les algorithmes. Ce sont « des couches de textes écrites par des programmeurs, qui font circuler des rapports de pouvoir aussi bien symboliques qu’économiques »[^3].

🔗 enjeux politiques de l’écriture numérique

Ces mêmes développeurs ont le pouvoir de permettre aux utilisateurs les moins expérimentés de prendre le contrôle de leur machine. Par le texte (code) ils vont permettre à d’autres de lire en concevant des interfaces 🔗. Si elle sont suffisamment abouties, elles peuvent effacer la machine, l’assujettir. Elle devient alors le « prolongement de la volonté humaine »[^3].

« tantôt d’humains qui ont du apprendre à la manier et à lui parler pour qu’elle s’exécute (programmeurs), tantôt d’humains qui peuvent très bien tout simplement l’oublier (les utilisateurs) »[^3]

Du même geste, les dispositifs d’architexte occultent la « dimension processuelle de l’activité computationnelle »[^3] derrière des interfaces. Les utilisateurs deviennent incapables de comprendre leur outil et ne voient dans l’affichage que des interactions limitées.

Fausseté

Bien qu’elle permette de lire du texte, la machine informatique n’est pas à proprement parlé une machine à écrire. Elle permet en effet de manipuler du texte, mais il est vide de sens. À force de se focaliser sur le texte informatique, on oublie la machine, sa mécanique et une certaine contingence dans l’exécution d’une texte qui n’est pas toute puissance.

🔗 code source

« Ce qui est inscrit, ce sont des données sous forme éléctromagnétique dans un disque dur. Ce qui est affiché, ce sont des lettres, des images, des mots, des vidéos… Tout un ensemble sémiotique qui nécessite un incessant passage, une conversion entre l’inscrit (le technique) et l’affiché (le sémiotique) »[^5] (p.47)

On ne considère le processus informatique que par l’écran, par le texte qui constitue son code source, puis par le texte de la console qui atteste de la progression de l’exécution et enfin par le texte résultant de l’opération. Finalement, on ne prend jamais véritablement le contrôle matériellement de la machine. Selon les langages de programmation, le texte permet un contrôle plus ou moins direct.

🔗 strates des langages de programmation

Pour générer une page web, on peut directement saisir le HTML et le CSS ; ajouter du JavaScript pour modifier les intégrations des deux premiers langages ; générer tout ces langages en via PHP (ou même du JavaScript, les mêmes langages peuvent être utilisés à différents temps de l’exécution).

[^1]: Yves Jeanneret et Emmanuel Souchier, L'énonciation éditoriale dans les écrits d'écran, 2005 [^2]: Emmanuel Souchier, L'écrit d'écran, pratiques d'écriture & informatique, 1996 [^3]: Cléo Collomb, Faire compter les machines, 2017 [^4]: Cléo Collomb et Samuel Goyet, Do computers write on electric screens?, 2016 [^5]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^6]: Yves Jeanneret et Emmanuel Souchier, Pour une poétique de l’écrit d’écran, 1999

artefact logiciel

id : 20211020104256
dernière édition :
type : architecture

Les artefacts d’un logiciel sont ses composants remarquables. On peut en trouver à différentes échelles de la structure du logiciel 🔗. Il s’agit notamment des modules 🔗, sous-systèmes et structures de contrôle 🔗[^1] (p.2).

[^1]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

base de données

id : 20200623180525
dernière édition :
type : architecture
mots-clés : REVUE

🔗 système d’information

Une base de données est une collection organisée de données, ainsi sont une base de données :

  • un meuble de fiches 🔗 ;
  • un fichier tableur ;
  • un fichier JSON ou XML ;
  • un SGBD (système de gestion de base de données), relationnel ou non.

L’objectif d’une base de données est de structurer l’information pour pouvoir y accéder plus efficacement. On cherche à pouvoir effectuer le SCRUD (Search, Create, Read, Update and Delete). Pour cela, on va formaliser les entrées à l’aide de formulaires 🔗, normaliser les contenus et mettre en place des systèmes de recherche entre eux à l’aide de métadonnées 🔗.

Structure par les métadonnées

Dans le cas d’une base de fiches 🔗, les métadonnées 🔗 sont le titre, la date, l’auteur… Elles ne font pas partie du propos de la fiche, mais permettent d’identifier les fiches et de les situer dans l’espace de la base (donc de les y retrouver), mais aussi depuis l’extérieur.

Cette structure se base sur des modèles 🔗 de données, des métaphores de la réalité permettant de la manipuler. Ainsi, on pourra créer une base de personnes et identifier (comme dans la vie quotidienne) par leur nom, leur prénom, leur âge… et ainsi pouvoir les traiter avec les capacités computationnelles 🔗 de l’informatique. La programmation orientée objet 🔗 permettra ensuite de manipuler ces métadonnées (devenues attributs) et d’accorder à ces entités des actions (méthodes).

Relation

Les données n’ont de sens que reliées et pour se faire il faut mettre en place des fonctions relationnelles au niveau des métadonnées pour combiner les données, les faire entrer dans le système d’information.

Ce travail théorique est guidé par le document modèle conceptuel de données, soit une modélisation théorique des métadonnées. Cela nécessite notamment la mise en place des clés afin que chaque objet de la base de donnée soit identifié individuellement dans l’espace de nom 🔗 et puisse être mis en relation avec d’autres.

Clés

On appelle clé primaire l’identifiant unique d’un objet. Il devient clé étrangère dès lors qu’il est appelé hors de son modèle d’origine. Ainsi l’identifiant unique (clé primaire) d’utilisateur devient clé étrangère lorsqu’il est référencé dans le modèle des adresses pour indiquer que tel utilisateur réside à telle adresse.

Recherche

Le parcours (browsing) d’une base de données relationnelle peut être effectué grâce au langage SQL (Structured Query Language), mais il existe d’autres langages comme SPARQL pour parcourir les éléments du web sémantique 🔗.

On appelle noSQL les bases de données non-relationnelles : elles possèdent un moteur propre afin d’optimiser la liaison de bases colossales, quand les logiciels communs prendraient trop de temps.

BEM, Bloc Element Modifier

id : 20200715212459
dernière édition :
type : inscription
mots-clés : technique

Le BEM (Bloc Element Modifier) est une convention de nommage des objets du DOM 🔗. Elle s’applique aux fichiers HTML. Cette convention permet de structurer la sélection des objets et donc l’affectation des méthodes (CSS 🔗 et JavaScript 🔗) avec une approche modulaire 🔗.

Ci-dessous on trouve deux codelets : un extrait de HTML avec la convention de nommage BEM et un extrait de SCSS (langage transpilé 🔗 en CSS).

<div class="btns-content">
    <button class="btns-content__btn"></button>
    <button class="btns-content__btn btns-content__btn--big"></button>
    <button class="btns-content__btn"></button>
</div>
.btns-content {
    backgound-color: red;

    &__btn {
        width: 50px;
        border: none;
        backgound-color: gray;
        color: black;

            &--big {
                width: 100px;
            }

        &:hover {
            backgound-color: black;
            color: white;
        }
    }
}

Dans l’objet HTML btns-content__btn--big on distingue successivement trois chaînes :

  1. le Bloc : btns-content
  2. l’Element (précédé des deux underscores) : btn
  3. le Modificateur (précédé des deux tirets) : big

Ce dernier est un duplicata de l’Element, mais soumis à des règles de style différentes. L’Element est quant à lui soumis au Bloc en tant que son enfant. Cette relation de parenté vient du fait que l’Element est dépendant du Bloc qui lui est autosuffisant : le Bloc a un intérêt à être multiplié dans la page contrairement à ses enfants qui ne sont inscrits que pour lui apporter du contenu.

Ce principe d’autosuffisance renvoie directement au concept d’objet 🔗 informatique héritant de méthodes et attributs et destiné à être instancié, reproduit. Ainsi, le BEM prolonge le DOM comme espace orienté objet. C’est pour cela qu’on parle également de OOCSS (Object Oriented CSS).

bibliothèque logicielle

id : 20210417145938
dernière édition :
type : programmation
mots-clés : Samuel Goyet

Les bibliothèques (code library, parfois traduit par librairies de code) sont des ensembles de fonctions 🔗, classes réutilisables par les développeurs dans leur code source. Ils incluent le(s) fichier(s) dans leur arborescence et peuvent ainsi profiter d’une code déjà écrit, prescrivant certains processus dans un domaine d’usage défini « plutôt que de réinventer la roue à chaque programme »[^1].

Par exemple, les bibliothèques suivantes prescrivent des processus dans les domaines cités :

  • VisJs pour la création de graphes
  • BeautifulSoup4 pour le web scraping

Les bibliothèques sont en général open source 🔗 et instaurent une « économie de l’écriture »[^1] du code source, un échange continu et collaboratif entre les développeurs.

🔗 communauté de développement

Conception

Les bibliothèques disposent des fonctions et classes généralistes dans un domaine particulier. Elles doivent reposer sur une interface de programmation 🔗 claire et sont accessibles aux développeurs grâce à leur documentation 🔗 dédiée.

[^1]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

boîte à outils programmable

id : 20210303174716
dernière édition :
type : processus
mots-clés : technique

Les boîtes à outils (ou toolkit) sont des outils de développement permettant d’automatiser certaines tâches au sein de l’arborescence. Il s’agit d’opérations systématiques et massives sur un ensemble de fichiers. Soient qu’ils sont issus du même répertoire et/ou avec une extension définie. Ils sont alors pris dans un traitement programmé dans différents tuyaux (pipes).

Plusieurs opérations peuvent être exécutées dans ces tuyaux. Nous distinguons :

Ces opérations sont déclenchées par des commandes, le plus souvent via une l’interface textuel du temrinal.

Cas

Avec des outils comme Gulp et Grunt, on peut par exemple pour tous les fichiers .png (images) contenus dans le répertoire assets/img définir une taille et un niveau de compression pour les transpiler en .jpg (images compressées). On peut faire passer ces mêmes fichiers dans un autre tuyaux pour les renommer, changer leur emplacement. De la même manière on peut transpiler une série de fichiers CoffeeScript en fichiers JavaScript que l’on vient ensuite minifier.

L’outil Webpack est quant à lui un outil de « paquetage » (bundle). Il permet d’assembler tous les contenus (bibliothèques, scripts, images, typographies, données…) d’une application web en un unique fichier bundle.js à relier à la page web.

brutalist web design

id : 20200710094139
dernière édition :
type : processus
mots-clés : site web

🔗 le design

Traduction du site brutalist-web.design qui présente les différentes caractéristiques du brutalist web design, design minimaliste de site web.

Voici une liste de site du genre : https://brutalistwebsites.com/

Le premier et principal objectif de ce type de design et de centrer l’attention sur l’utilisateur.

Lisibilité du contenu

Par défaut, un site web qui emploi du HTML valide et n’a pas de style personnalisé sera lisible sur tous les écrans et appareils. Seule une mauvaise conception peut rendre le contenu moins lisible.

Guider l’interaction

Un site web est un document hypertexte qui permet deux formes principales d’interaction : la navigation d’un lien vers un autre endroit et la soumission d’informations à un serveur. Ces fonctions sont assurées, respectivement, par des hyperliens et des boutons. Bien que JavaScript permette à n’importe quel élément de répondre à un clic, les zones cliquables d’une page qui ne sont pas manifestement des hyperliens ou des boutons peuvent dérouter le visiteur.

Design des interrupteurs

Un hyperlien n’a pas d’analogue dans le monde réel. Depuis l’aube du web, la convention veut qu’un hyperlien utilise un soulignement pour révéler son existence (ce qui est une merveilleuse solution, puisque le soulignement n’a pas sa place dans les compositions papier modernes).

Les boutons rendus dans un navigateur doivent ressembler aux boutons rendus sur le système d’exploitation de l’ordinateur qui exécute ledit navigateur.

Le bouton retour fonctionne

Tous les navigateurs ont un bouton intégré appelé « bouton retour ». Ce bouton est une forme d’« annulation », qui ramène l’utilisateur à l’endroit où il se trouvait avant son dernier clic de navigation. Cette acte doit être possible à tout instant et sous cette forme.

Un site se lit en scrollant

Un site web n’est ni un livre ni un magazine. Parce qu’il est visualisé dans un navigateur, les utilisateurs peuvent faire défiler la fenêtre du navigateur pour lire un contenu qui ne peut pas tenir sur un seul écran. Il faut respecter le rythme du visiteur et non le contraindre avec du JavaScript.

Les décorations, si besoin

Un site web n’est ni une application ni un jeu vidéo. Il est destiné au contenu et à l’internaute.

La performance est une fonctionnalité

Les sites web ne sont pas physiques comme un livre ou un magazine. Leur contenu doit être téléchargé sur un réseau informatique, puis rendu dans un navigateur web. Cela prend du temps et de l’énergie.

callback et promesses JavaScript

id : 20200705083336
dernière édition :
type : programmation
mots-clés : technique

🔗 fonctions

Les fonctions sont parfois pourvues d’un return, un renvoi. Une fois les opérations terminées au sein de la fonction, une valeur est renvoyée à l’extérieur de la fonction. Il est aussi possible que le renvoi doit se faire vers une autre fonction, sans sortir d’un processus asynchrone.

🔗 comportement logiciel

Le callback (rétroaction) est une fonction intégrée dans une autre qui va prendre la suite de l’opération, sa continuité. Elle peut être passée en paramètre de la fonction comme ci-dessous :

function faireQlqChose(value, successCallback, errorCallback){
	// traitement

 if(isOk) {
     successCallback(newValue);
 } else {
     errorCallback(value)
 }
}

function successCallback() {
	// opération en cas de réussite
}

function errorCallback() {
	// opération en cas d'échec
}

C’est une méthode peu souple, intellectuellement très exigeante tant elle peut devenir abstraite par les multiples mises en abîme. Elles est aussi obsolète. Désormais, le JavaScript intègre l’objet Promises (promesses). Elles consiste à un renvoi externe à la fonction, mais sans casser le processus asynchrone, comme ci-dessous :

🔗 javascript langage de programmation

function faireQlqChose(value){
  return new Promise((successCallback, failureCallback) => {
    // traitement
    if (isOk) {
      successCallback(newValue);
    } else {
      errorCallback(value);
    }
  })
}

faireQlqChose()
	.then(function(successValue) {
    // première opération en cas de réussite
	})
	.then(function(successValue) {
    // seconde opération en cas de réussite
	})
	.catch(function(failureValue) {
    // opération en cas d'échec
	})

Lutter contre le callbackhell, la sur-incrémentation : http://callbackhell.com/

carnet de programmation

id : 20201222132128
dernière édition :
type : architecture
mots-clés : médiation

🔗 architexte

Comme les éditeurs de texte, les notebook permettent d’inscrire du code, de le commenter, mais avec en plus la possibilité d’un rendu visuel instantané des instructions. Il est ainsi plus facile pour le développeur d’expliquer sa démarche.

Exemples de notebook :

  • Codepen
  • Jupyter
  • Observable

Ce sont des « carnet numérique programmable »[^1] permettant de mettre en place graphiquement un environnement de développement en répartissant visuellement (sections) des variables, des fonctions, des commentaires de code, mais avec en plus un rendu régulier de l’état du programme (message de la console ou rendu graphique). Ce sont autant d’instructions (par le code vers la machine, par les commentaires vers l’utilisateur) qui créent une médiation interactive très complète entre le développeur et le lecteur du code source pour donner un « essai computationnel », un « document-machine »[^1].

« Le notebook facilite la documentation de certaines méthodologies, en particulier quantitatives. Son pouvoir authentificateur réside dans son caractère dynamique : il permet par exemple de faire varier un paramètre dans un dispositif expérimental pour modifier les graphiques qui en découlent, voire d’éprouver tout un processus en remplaçant les données initiales par d’autres. Ce faisant, il vise une recherche reproductible, réplicable, robuste et généralisable. »[^1]

La modification (locale) d’un artefact numérique dans l’interface modifie le comportement final du programme, mais aussi tous les rendus intermédiaires, tout ce qui permet à l’utilisateur d’appréhender le fonctionnement du programme. Il peut modifier le code sans incidence sur l’expérience des autres utilisateurs juste pour enrichir la sienne et ainsi pouvoir reproduire tout ou partie du programme. On a là plus qu’une lecture du code, mais une véritable étude d’un programme avec la possibilité de le réutiliser.

🔗 logiciel libre et logiciel open source

[^1]: Arthur Perret, Fonction documentaire de preuve et données numériques, 2020

centralisation

id : 20200909184744
dernière édition :
type : processus
mots-clés : politique, Anthony Masure, REVUE

La centralisation est un bras de fer politique. Il s’oppose radicalement à la culture web du pair à pair (« peer to peer »), celle de l’échange de contenu entre les usagers, à la fois créateurs et consommateurs, capables d’exploiter pleinement leurs outils : ordinateur et ses logiciels, le Web. Elle s’oppose à la culture du libre 🔗.

🔗 production de contenu web

Nous sommes dans une étape de récupération du Web par les organisations privées qui voient dans la simplification des interfaces et la récolte de données personnelles (via les applications 🔗) des intérêts économiques. Ils centralisent les données, les usages, tous cachés derrière des interfaces opaques pour les utilisateurs, limitées pour les développeurs.

Alors que l’informatique venait apporter à chacun la possibilité de s’approprier pleinement un outil de travail et de création complexe, les utilisateurs sont invités à s’investir dans des écosystèmes simplifiant à l’extrême leur rapport à leur machine.

« C’est le modèle de la vitesse, du gain de temps. Dans cette optique, certains peuvent ainsi écrire que ‹ Linux est gratuit si votre temps n’a pas de valeur › »[^1]

Linux a beau être gratuit, il a un coût d’entrée très élevé.

Mouvements de perte

  • les logiciels sont bornés dans des environnements propriétaires, fermés et deviennent des applications perpétuellement mise à jour et pour lesquels il faut parfois payer un abonnement ;

🔗 application

  • la capacité de création et recherche de l’ordinateur est externalisée dans le cloud, dépossédant l’utilisateur de son outil pour l’endetter dans des abonnements aux services de machines virtuelles.

🔗 cloud

« Le cloud renvoie directement au Minitel, qui ne comprenait ni stockage de données ni processeur de calcul »[^1]

« Si le cloud computing incarne la concentration des capitaux et forces de production, le home computing est du côté de l’interopérabilité, qui permet à des machines diverses donc différentes de fonctionner ensemble »[^1]

On nous prend nos outils de production et on paie pour les utiliser. Les gens vont le faire parce que le service sera plus performant, sécurisé.

Perte de la capacité à créer

« Tout comme l’application nous retire la possibilité de créer des liens hypertextes, le cloud détruit progressivement la notion de fichier »[^1]

L’utilisateur perd la capacité de créer du lien entre les fichiers, mais aussi de créer des fichiers. Nous perdons peu à peu en littératie, ne comprenons plus nos outils.

🔗 littératie numérique

[^1]: Anthony Masure, Le design des programmes, 2014

chaîne d’édition du code

id : 20210314113151
dernière édition :
type : processus

🔗 édition numérique

Le code source 🔗 est un document hybride, à la fois une interface permettant de comprendre le fonctionnement d’un programme pour un humain et une suite d’instructions pour la machine. Cette dernière n’a pas besoin d’un code lisible et soigné, mais simplement fonctionnel. Elle exécutera même plus efficacement un code moins verbeux, moins construit et avec au mieux un unique fichier minifié 🔗. Les humains ont au contraire besoin de travailler sur un espace et un temps d’exécution ; sur une série de fichiers avec des jalons réguliers dans le code source pour attester de son bon fonctionnement et gérer sa complexité 🔗.

Pour réunir ces deux matériaux en un espace de travail, les développeurs utilisent des outils programmables 🔗. La programmation lettrée 🔗 tente de fusionner ces deux approches. Elle invite les développeurs à inscrire un code très verbeux qui va ensuite être traité par un programme qui va séparer le fonctionnel de l’explicatif pour optimiser (rendre plus efficient) un rendu pour les humains et un autre pour les machines.

Lorsque l’on télécharge une bibliothèque 🔗, on peut souvent trouver dans le dépôt une version destinée à être lue par les développeurs (elle est commentée, avec messages d’erreur) et une version empaquetée 🔗 (dite « de production ») destinée à l’exécution.

chiffrement

id : 20210418214149
dernière édition :
type : inscription
mots-clés : technique

Le chiffrement permet de verrouiller l’accès à des informations (chaînes de caractère, voire des fichiers entiers), d’authentifier une transaction (intégrité, authenticité). Son application varie selon les algorithmes.

Le chiffrement n’est pas le codage (en base 64, par exemple) qui consiste simplement à transformer une chaîne pour un système de lecture.

Le chiffrement est un procédé de cryptographie, de protection de l’information.

Déchiffrement

Le déchiffrement consiste à retrouver le contenu original (son accès) d’un document chiffré. Il est possible d’ajouter du sel lors du chiffrement pour augmenter le temps de déchiffrement.

Il est possible d’inverser le processus de chiffrement grâce à une clé, selon deux processus distincts.

  • chiffrement symétrique, la même clé permet de chiffrer et déchiffrer l’information ;
  • chiffrement asynchrone, on utilise une première clé publique (lisible par son utilisateur) pour chiffrer l’information et une seconde (appliquée par le service cible) pour la déchiffrer.

Le décryptage consiste à retrouver le contenu original du document sans utiliser la clé de déchiffrement. Il n’est pas possible de « crypter » un document étant donné qu’il est nécessaire de créer une clé pour chiffrer un document (sans quoi on ne pourrait en théorie par le déchiffrer).

classe abstraite

id : 20210915100951
dernière édition :
type : programmation

Dans le jargon de la programmation, l’abstraction 🔗 « identifie et regroupe des caractéristiques et traitements communs applicables à des entités ou concepts variés »[^1]. On créer ainsi un modèle 🔗.

En programmation orienté objet 🔗, il est possible de réaliser des classes abstraites. Ce sont des modèles 🔗 de classe ; elles ne sont pas destinés à être instanciés, mais uniquement à prescrire des attributs et méthodes dont d’autres classes vont hériter.

Dans l’extrait de code ci-dessous, la classe User hérite de l’attribut path et de la méthode add de sa classe parente Database qui lui prescrit impérativement la méthode search.

abstract class Database  {
    private  $path;

    abstract function search($item);

    function add() {
        …
    }
}

class  User  extends  Database  {
    private  $id;

    function search($item) {
        …
    }
}

[^1]: Wikipédia, Abstraction (Informatique)

client serveur

id : 20210112090725
dernière édition :
type : architecture

Le mode de transaction « client-serveur » permet de distinguer ces deux machines selon leur rôle dans un échange de données, tel que :

  • client : envoie des requêtes 🔗 en attente d’une réponse ;
  • serveur : attend les requêtes des clients et renvoie une réponse au client.

La seconde machine est en générale puissante et peut faire appel à d’autres serveurs (en prenant la position de client le cas échéant) pour exécuter des tâches complexes. Ce que ce qu’on désigne par client est souvent un ordinateur personnel, bien moins puissant.

C’est aussi une distinction d’environnement d’exécution 🔗. Les serveurs web de manière générale possèdent les environnements pour exécuter les langages de programmation PHP, Python, JavaScript ou Ruby, mais les clients (navigateurs web) ne peuvent interpréter que le HTML, le CSS et le JavaScript. Ces trois composants peuvent ainsi être générés depuis le serveur avec le langage (et son runtime) choisi.

cloud

id : 20200714155845
dernière édition :
type : undefined
mots-clés : service

Service

Pour les particuliers, c’est un service en ligne de stockage de fichier, mais pour les entreprises, le cloud computing correspond à un ensemble de services proposés en SAAS (Software As A Service) par des entreprises comme Amazone, Microsoft et Google selon trois grandes familles :

  • Stockage d’objet
  • Machines virtuelles
  • Cloud privé

La force du cloud est sa flexibilité. Contrairement à un hébergement classique où l’on paie au mois, à l’année une infrastructure pour un niveau de prise en charge (stockage, bande passante, puissance de calcul et puissance de charge), le cloud permet de rapidement monter une infrastructure payée à la minute (voire à la seconde) d’utilisation et dont il est possible de baisser ou monter la charge selon les besoins, en fonction des moments de la journée.

Maintenance

On différencie la disponibilité et la durabilité des données. Ce sont deux taux (estimés entre 95% et 99,99…% ) traitant respectivement de la possibilité d’accéder aux données et celle de les conserver. En effet, lors d’un transfert, d’une distribution, il est possible qu’il y est des interférences et que des données soient perdues. Il est possible d’accéder à l’objet, mais son intégrité n’a pas été respectée.

🔗 la donnée

code source

id : 20200906135907
dernière édition :
type : inscription
mots-clés : Bruno Bachimont, Wendy Hui Kyong Chun, Cléo Collomb

Aux débuts de l’informatique, le terme « code » désigne le « code machine », un langage de très bas niveau 🔗. C’est de ce dernier dont il est question dans ce document.

Le terme « code » suggère d’emblée que ce qu’il désigne est une inscription prise dans un processus d’exécution, de transformation de l’information dans un flux. Les informations transmises par le code source ne sont que pures instructions ; il ne sert qu’à faire fonctionner, même si finalement il n’aboutis pas.

« Qu'il puisse ou non s'exécuter, le code peut, doit être, transformé en quelque chose de significatif »[^3]

Vide de sens

Le code machine est un système de symboles élémentaires (dont les unités ne peuvent être décomposées et sont indépendantes les unes des autres, dans un système discret 🔗) et arbitraires (ils sont dépourvues de signification intrinsèque, ne donnent pas d’indice sur ce qu’ils codent).

« Programmer c’est manipuler aveuglement des symboles »[^2]

Le 0 et le 1 du binaire sont ainsi vides de sens. Ce sont des abstractions 🔗 : ils remplacent des valeurs dans le simple but de les rendre calculable. C’est possible car le code doit être sans ambiguïté (chaque symbole a une seule signification, c’est la monosémie) et peut être manipulé mécaniquement, par le calcul. Le code est « pure puissance de manipulation »[^1] et le calcul une « représentation graphique de l’activité de la machine »[^3].

🔗 inscription computationnelle 🔗 grammatisation

« Le numérique ne dit pas ce qu’il calcule et c’est pourquoi on peut calculer n’importe quoi. »[^1]. Dès lors que l’on peut coder quelque chose, on peut l’exécuter ; la difficulté est donc de savoir ce que l’on peut coder et comment, de faire une herméneutique du code : interpréter son sens caché et le contenu qu’il produit. Il faut « articuler l’arbitraire du code et l’arbitraire du signe »[^1]. Selon Bruno Bahimont, le code est autothétique, « se manipule indépendamment de ce qu’il signifie et indépendamment de la matière sur laquelle il s’exécute »[^1]. Une structure de contrôle n’a pas besoin de renvoyer à un élément réel pour fonctionner efficacement.

Le code source (et sa compréhension, lisibilité) va être stabilisé grâce à des langages formels et paradigmes de programmation permettant de faire une ingénierie de cet outil. Aussi, on empruntera le nom d’éléments réels, le jargon de métiers pour suggérer le composition du système aux lecteurs.

Code fétiche

« La grande difficulté de la raison computationnelle c’est que le calcul ne se voit pas. Le calcul s’exécute. »[^1]

Si l’on remonte dans les couches logicielles, les langages de programmation alphanumériques nous permettent d’écrire un texte compréhensible avec un peu de contexte pour qui lit l’anglais. On peut ainsi lire le code, constater le résultat de l’opération, mais pas assister à la compilation, ni au traitement. C’est une boîte noire. On peut tout au plus recevoir certaines alertes d’une console quand l’environnement d’exécution 🔗 le permet.

Ainsi, on ne peut réduire « l’exécution à l’inscription », le « technique au sémiotique »[^4] et l’instruction au résultat. À force de donner trop d’importance à l’écrit en informatique, on finit par :

« convertir l’action computationnelle en langage, le temps en espace, l’événement en localisation, le technique en sémiotique »[^4]

🔗 performativité du code

Le code n’est la source d’aucune action avant d’avoir été compilé 🔗 (pour être exécuté) et identifié comme source[^3]. L’idée de code source est une idée de traçage, de sourcing, avant d’être une question d’écriture, hors cette idée revient à fétichiser 🔗 les programmes.

« Il n’y pas de translation parfaite entre une exécution (computationnelle) et une inscription (textuelle), entre l’acte et le langage, entre le processus temporel qu’est l’exécution du programme et l’espace du code »[^4]

Échelle

Le code est un outil général. Le vide de sens qu’il incarne, ordonne et cette non ambiguïté permettent de formuler une quasi infinité d’algorithmes, de système logiques et donc de développer autant de formes, de fonctionnalités. Les limites sont matérielles et intellectuelles et sans cesse repoussées. Les machines sont plus puissantes et les techniciens créer des interfaces pour simplifier le développement, les langages de programmation.

Les langages de programmation 🔗 sont des outils particuliers. Ils viennent se superposer à cette immensité créative qu’est le code machine et l’ouvre pour un plus grand nombre de personnes grâce au travail technique de certaines. On sacrifie la généralité pour une plus grande efficacité.

[^1]: Bruno Bachimont, Rhétorique de l’intelligibilité, vers des humanités du numérique, 2020 [^2]: Bret Victor, Drawing Dynamic Visualizations, 2015 [^3]: Wendy Hui Kyong Chun, On ‹Sourcery›, or Code as Fetish, 2008 [^4]: Cléo Collomb, Faire compter les machines, 2017

coder, programmer ou développer ?

id : 20210809190021
dernière édition :
type : undefined

Nous allons tenter de faire la distinction entre trois pratiques appartenant à différents métiers afin d’analyser les différents niveaux de compétences nécessaires aux praticiens. Le code est inhérent tant à la programmation qu’au développement.

On écrit du code pour prescrire le fonctionnement d’un ordinateur afin de répondre à un besoin, à une spécification 🔗. Le processus de développement va aborder cette réponse par l’analyse dans le système du logiciel. Cela pour une réponse cohérente, évitant les dysfonctionnements dans le système.

La programmation suite cette phase d’analyse, il s’agit de l’implémentation 🔗, de la reformulation de la solution

coloration syntaxique

id : 20200918100545
dernière édition :
type : inscription
mots-clés : outil

🔗 syntaxe de code

On retrouve la coloration syntaxique dans la plupart des logiciels d’édition texte. Des expressions régulières permettent d’évaluer les chaînes de caractère selon qu’il s’agisse de mots-clés ou bien précédant/suivant des mots-clés et/ou caractères remarquables. Il ne s’agit pas d’une identification sémantique ; ça n’est pas le sens des termes qui permet de les colorer, mais bien leur seule composition en fonction du langage analysé.

Si la typographie est de manière général à châsse fixe (monospace), les variations de couleur, de graisse et d’inclinaison permettent de distinguer certaines chaînes dans le corps du texte. Il n’est toutefois pas prouvé que la mise en évidence de ces chaînes avait un effet bénéfique sur la compréhension des programmes pour les novices en programmation[^1] (p.3). Hors l’idée originale de la coloration syntaxique est bien de réduire substantiellement le temps de compréhension des caractéristiques d’un code donné.

Utilisation

On observe souvent un effet sapin de Noël avec une large variété de mises en forme pour que finalement on ne sache même pas ce qu’elles signifient. Cet effet peut polluer d’autres indications visuelles bien utiles, car liée à un contexte spécifique. Nicolas Rougier[^1] (p.3) prend l’exemple des « parenthèses arc-en-ciel » (rainbow parenthesis) avec lesquelles chaque niveau d’imbrication est bien visible. Il y a aussi la coloration des arguments d’une fonction. On peut imaginer qu’une variable puisse être colorée en fonction de sa portée 🔗, de son type.

La coloration syntaxique aussi utile lorsqu’il s’agit de partitionner un texte dans le temps ou entre des auteurs[^1] (p.3). Une couleur identifiera un premier auteur/une version antérieur et une autre un autre auteur/la version actuelle.

Des logiciels comme Zettlr vont aller plus loin dans la coloration syntaxique, allant bien plus loin dans la transformation des caractères, en taille, en graisse.

[^1]: Nicolas Rougier, On the design of text editors, 2020

commentaire de code

id : 20201220084534
dernière édition :
type : programmation
mots-clés : médiation, technique

C’est une forme d’annotation du code source. La syntaxe de commentaire varie selon les langages, mais il en existe en général deux types : les commentaires sur une ligne et les blocs de commentaire.

Le commentaire de code à différents usages :

  • désactiver une partie du processus : les instructions commentées ne sont plus compilées/interprétés et le programmeur peut ainsi tester son programme en faisant interrupteur sur les structures de contrôle ;
  • préciser une instruction : avec un commentaire sur une ou plusieurs lignes, le programmeur peut expliciter un flux de contrôle long ou peu explicite ;
  • documenter le code 🔗 : disposer des encadrés dans les fichiers pour commenter les intrants, extrants, auteurs ou même les tâches à accomplir.
activeFunction();
// inactiveFunction();

/**
Code mort, inactif :
var inactiveVar = true;
inactiveFunction();
**/

activeFunction();

communauté de développement

id : 20210326162804
dernière édition :
type : undefined
mots-clés : Flore Barcellini

Les projets open source 🔗 sont ouverts et continus dans le sens où tout le monde peut intervenir dans le cycle de développement 🔗 (par l’échange ou directement le code) et que de nouvelles fonctionnalités peuvent toujours être apportées aux logiciels.

L’échange continu du temps et des compétences de chacun, le partage de services (espaces de travail) gratuits, fait la force de ce modèle de production logicielle dont se sont emparés des milliers de personnes. Ils travaillent selon différents principes développés dans sa thèse par Flore Barcellini[^1].

Communauté

Une communauté se bâtie (elle-même, par elle-même) sur des règles (valeurs communes, gouvernance) et des objectifs communs. Ses membres partagent un sentiment d’appartenance (qu’ils basent sur des traditions et/ou une relation affective), un espace, des ressources, un langage (jargon) qui regroupent et délimitent la communauté.

« le jargon se rapproche de qui est décrit dans les collectifs de travail comme un langage opératif. […] Ce langage opératif a souvent un lexique et une grammaire plus restreints que le langage courant, il permet ainsi de minimiser le coût des interactions pour échanger des informations, et éventuellement se coordonner, contrôler la pertinence des actions de soi et des autres »[^1] (p.34)

L’intégration d’une personne dans la communauté se fait par cooptation, suite à sa participation. On intègre une personne selon la représentation que les membres de la communauté ont d’elle. Ainsi, chaque membre à une représentation de ses pairs. Les communautés de développeurs sont particulièrement sensibles à la culture des hackers 🔗 et cette représentation se base largement sur la compétence de la personne.

Compétence

Un développeur doit être un minimum polyvalent dans ses compétences 🔗 pour pouvoir satisfaire les besoins épistémiques (apprendre, produire et échanger des connaissances au sein et en dehors du groupe) d’un projet. Il s’agit d’un code source, mais aussi d’une équipe reposant sur un réseau 🔗.

Des documents comme la convention de développement 🔗 permettent de coordonner les personnes et leurs efforts.

« Le couplage renvoie à la nature et à l’intensité des interactions nécessaires pour pouvoir réaliser une tâche […] la conception collaborative est considérée comme une tâche fortement couplée »[^1] (p.46)

Conception

La conception consiste à « clarifier des spécifications »[^1] (p.50) 🔗 et faire le suivi de la résolution pour maintenir de la cohérence dans les échanges. Pour résoudre formaliser des problèmes, on peut utiliser le modèle « QOC » pour « Questions Options Critères ». Le critère sert à la validation des options choisies pour une question donnée.

Activité

Espaces

Les membres de ces communautés se partagent le travail principalement au travers de trois espaces :

  • espace de discussion : (forums en ligne, listes de diffusion) pour échanger sur les contributions, s’entraider ;
  • espace de documentation  : (site web) pour expliquer le fonctionnement et permettre de localiser les ressources (modules, bibliothèques, debug) ;
  • espace d’implémentation (et téléchargement) : (VCS en ligne) stockage du code source et jalonnement des versions du code source et des opérations de maintenance.

Rôles

Flore Barcellini distingue[^1] (p.18) plusieurs rôles dans la communauté d’un logiciel libre :

  1. les utilisateurs : utilisation (et retours) du logiciel ;
  2. les développeurs : maintenance avec un niveau de modification variable du code source ;
  3. les administrateurs : les core developers (membres de la core team) sont chargés de la conception générale du logiciel. Ce sont les architectes du logiciel 🔗.
flowchart

discussion
documentation
implémentation

utilisateurs -->|demande assistance| discussion
utilisateurs -->|installation, configuration| documentation
utilisateurs -->|téléchargement| implémentation

développeurs -->|spécification| discussion
développeurs -->|argumentation ?| documentation
développeurs -->|modification| implémentation

administrateurs -->|arbitrage| discussion
administrateurs -->|contrôle| documentation
administrateurs -->|contrôle| implémentation

Un rôle est un « phénomène émergeant de l’interaction […] tenu par un individu en fonction des activités qu’il met en œuvre »[^1] (p.54). Les participants peuvent se partager trois rôles distincts[^1] (p.57-59) :

  • médiateur (externe) : ils « traversent des frontières en transférant des informations et des pratiques ». Les frontières peuvent être organisationnelles ou techniques et en les dépassant il inclut les gens. 🔗
  • leader (central) : « la position adoptée par une, ou plusieurs personnes, pour conduire un groupe ». Ça n’est pas un chef statutaire (manager), nommé par une institution, mais une personne « reconnu pour ses compétences par les autres membres du groupe ». Ils ont une autorité, mais aussi une influence.
  • expert (interne) : ce sont des « concepteurs d’exception », ils sont les plus habiles : ils mobilisent plus facilement leurs connaissances et disposent intuitivement un bon cadre de travail. Ainsi, ils accomplissent rapidement des tâches plus complexes. Ils ont tendance à devenir des leaders lors des « réunions de conception peu structurées ».

[^1]: Flore Barcellini, Conception de l’artefact, conception du collectif, 2018

compétences du développeur

id : 20210908111616
dernière édition :
type : undefined
mots-clés : Flore Barcellini

Le développeur est un professionnel de la résolution de problèmes. Il travaille dans « domaine sémantiquement riche »[^4] (p.1), à la fois par ses outils de travail que sont les langages de programmation 🔗 et par le domaine qu’il vient solutionner et qu’il doit comprendre.

Variété des compétences métier

Flore Barcellini[^1] (p.64) nous permet de dresser l’arborescence de compétences ci-dessous, utile à chaque développeur. Le développeur travaille à pour des utilisateurs, mais aussi avec ses pairs.

  • technique : être un technicien expérimenté ;
    • conception : langages et méthodes de programmation ;
    • usage : méthodes et gestion de la charge de travail, évaluation du produit ;
  • discursif : être adaptée à l’interaction en groupe de co-conception ;
    • clarification (synchronisation cognitive) : définition des propriétés de l’objet en cours de conception ou de sa spécification pour sa modélisation 🔗 ;
    • coordination (synchronisation opératoire) : évolution et le maintien dynamique d’un contexte de connaissances, d’une représentation de la situation.

On demande deux axes de double connaissance aux développeurs. D’une part, à la fois celle de leur métier (résoudre de problèmes) et celle de leurs utilisateurs. Comment adapter la réponse technique aux usages des utilisateurs ? Pour faciliter ce travail, certaines grandes entreprise du numérique fournissent des guidelines à suivre, voire des SDK (software developer kit) permettant d’ignorer une partie du travail de conception de l’interface. D’autre part, à la fois d’avoir un savoir-faire individuel et de le sychroniser avec l’équipe et évolutions du métier.

« la programmation a, jusqu’à récemment, été plus un jeu d’invention qu’un jeu de communication […] Historiquement, pour réussir dans notre profession, il fallait être capable de rester assis seul pendant de longues heures sans parler à personne, en fixant des papiers ou des écrans. »[^3] (p.35)

Productivité

La productivité d’un développeur s’évalue à sa capacité à comprendre et à écrire des programmes 🔗. C’est une tâche difficile qui requière un certain niveau d’analyse et de connaissances purement techniques.

« la différence de productivité entre les meilleurs et les pires programmeurs est généralement d’un facteur 20 […] le programme qu’une personne peut écrire en deux semaines prendra à une autre un an - et le programme écrit en deux semaines sera souvent de meilleure qualité. Une implication pratique de ce résultat qui a été trouvé dans plusieurs études est que l’aspect le plus important de l’amélioration des projets logiciels est d’employer moins de programmeurs, mais de meilleure qualité »[^2] (p.47)

« les experts diffèrent des novices davantage par leur capacité à s’organiser à propos d’un programme que par la quantité absolue d’informations [gérées dans le programme] en soi »[^4] (p.553)

[^1]: Flore Barcellini, Conception de l’artefact, conception du collectif, 2018 [^2]: Jakob Nielsen, Usability Engineering, 1993 [^3]: Alistair Cockburn, Agile Software Development, 2002 [^4]: Ruven Brooks, Towards a theory of the comprehension of computer programs, 1983

complexité

id : 20210419170156
dernière édition :
type : processus

La complexité ne vient pas du nombre, de la « multiplicité des composants, ni même la diversité de leurs interrelations »[^1], mais de « l’imprévisibilité potentielle (non calculable a priori) des comportements de ce système »[^1].

« tant qu'ils sont pratiquement et exhaustivement dénombrables [les composants] on sera en présence d'un système compliqué (ou hypercompliqué) », ce qui est différent de complexe.

La complexité que l’on peut ressentir devant une carte vient de notre difficulté à la représenter, à nous projeter dans ce système de règles — bien qu’il soit simple.

[^1]: Serge Diebolt, Le petit lexique des termes de la complexité

complexité logicielle

id : 20210313105330
dernière édition :
type : processus

🔗 complexité

La complexité d’un logiciel entrave le projet dans le sens où elle rend difficile la compréhension de son fonctionnement. Il devient une boîte grise, dont on peut lire le traitement sans pouvoir le comprendre. Cette complexité peut venir de l’écriture du système, mais aussi de l’approche, des « contraintes [devenues] instables : les représentations du problème et des solutions évoluent en permanence durant le processus »[^3]. Il peut y avoir des coïncidences (sans cohérence avec les spécifications 🔗) dans le comportement du logiciel 🔗, hors on recherche avant tout la fiabilité du système.

« C’est l’imprévisibilité potentielle (non calculable a priori) des comportements de ce système, liée en particulier à la récursivité qui affecte le fonctionnement de ses composants (‹ en fonctionnant ils se transforment ›), suscitant des phénomènes d’émergence certes intelligibles, mais non toujours prévisibles. »[^1]

La complexité ne doit pas être abolie ou même interdite. Elle est aussi un outil permettant de systématiser le travail des collaborateurs du projet logiciel .

« Je conclus qu’il y a deux façons de construire un logiciel logiciel : Une façon est de le rendre si simple qu’il n’y a évidemment aucune déficience et l’autre façon est de le rendre si compliqué qu’il n’y a pas de déficiences évidentes. La première méthode est beaucoup plus difficile »[^5] (p.81)

Causes

Ben Moseley et Peter Marks[^6] (p.6) listent certaines causes de la complexité des logiciels :

La gestion de l’état

S’il est souvent efficace de redémarrer un programme (voire la machine entière) pour corriger un bug, c’est à cause des erreur de gestion de l’état du système. Un logiciel aux nombreux états (et sujet à autant de changement) est complexe et plus difficile à comprendre et à maintenir ou même à tester 🔗. Chaque strate logicielle 🔗 apporte son lot d’états et tous se combinent pour donner la complexité à aborder par les développeurs.

L’ordre des déclarations

Les contraintes quant à la gestion du flot de contrôle 🔗 par langages de programmation imposent souvent aux développeurs un raisonnement écrit artificiel. Ils n’ont pas la liberté de présenter leur raisonnement comme ils le souhaitent.

La quantité de code

Il est nécessaire pour réduire la complexité de réduire le volume de code[^6] (p.10). La lecture de chaque ligne (prenance en compte la lecture des paragraphes précédants) est un effort intellectuel important et une source d’erreur de compréhension.

Analyse du programme

Notre objectif est de limiter l’impact de la complexité sur la compréhension du logiciel, et ce par deux approches[^6] (p.4), la première formelle et la seconde informelle :

  • le test 🔗 pour tirer des observations sur le fonctionnement du logiciel et ainsi éviter de le voir que comme une boîte noire. Il s’agit de test unitaires (des programmes execute des parties du programme principal pour répondre de son fonctionnement) ou de revues complètes ;
  • le raisonnement pour tenter de comprendre le système en l’examinant, ainsi que ses commentaires.

« le raisonnement informel est de loin le plus important […] il y a des limites inhérentes à ce qui peut être réalisé par les tests […] raisonnement informel (inhérent au processus de développement) est pratiqué en permanence. L’autre justification est que les améliorations du raisonnement informel conduiront à moins d’erreurs, alors que les améliorations des tests ne peuvent que permettre de détecter davantage d'erreurs »[^6] (p.4)

et enfin, il faut simplifier, notamment en modularisant 🔗 le programme.

Décomposer en modules

Devant un système possédant de nombreux composants (issus de la structure du logiciel 🔗) on se retrouvera devant un système compliqué, (voire hypercompliqué 🔗). Imaginons un logiciel composé de 200 programmes, contenant de 5 à 10 modules, avec pour chacun 10 à 30 structures de contrôle. Ce système est compliqué, mais nous avons aussi exprimé qu’il était décomposé, structuré. Ainsi, si les modules 🔗 sont suffisamment stables (pas d’effet de bord 🔗 entre eux, pas d’imprevisiblité), un développeur pourra se concentrer sur quelques modules pour concevoir et inscrire ses structures de contrôle.

Sa charge cognitive 🔗 est suffisamment maîtrisée pour qu’il ne commette peu ou pas d’erreurs de programmation et qu’il puisse travailler efficacement. En conservant une architecture de qualité, les développeurs travaillent mieux et plus vite. On perd du temps pour en gagner.

« le programme devient plus compréhensible car il peut être résumé en quelques fonctionnalités clés – celle de chaque module – sans qu’il y ait besoin de rentrer dans le détail. L’interface, c’est-à-dire les façons d’accéder au module et à son action, en ‹ […] révèle le moins possible sur son fonctionnement interne › »[^4] (p.103)

Au contraire, si les modules 🔗 ne sont pas intégrées dans une architecture, à la fois souple et robuste, les développeurs vont devoir passer plus de temps à analyser un problème devenu complexe. Ils vont tenter en permanence de prédire un comportement qui n’est pas intuitif, qui est influencé par un trop grand nombre de paramètres.

Ainsi, un programme fait d’un millier de composants suffisamment stabilisés pour qu’on puisse travailler avec une dizaine est moins lourd qu’un programme de vingt composants à assumer intégralement. Une sommes aussi importante de composants va potentiellement alourdir le traitement, mais c’est le prix à payer pour un système maintenable.

« un logiciel complexe est, en effet, mieux considéré comme une toile qui a été délicatement assemblée à partir de matériaux simples. Nous comprenons un système compliqué en comprenant ses parties simples, et en comprenant les relations simples entre ces parties et leurs voisins immédiats »[^7] (p.1)

Effet

Cet effort d’architecture prend du temps et de l’espace mémoire. La complexité du projet va affecter le travail de développement

  • dans le temps pour décomposer, isoler, résoudre,
  • mais aussi dans l’espace pour inscrire (coder) cet effort et pouvoir le reproduire (relecture du code, documentation).

Cette configuration de travail s’appelle l’adhocratie. C’est la « configuration d’organisation qui mobilise, dans un contexte d’environnements instables et complexes, des compétences pluridisciplinaires et transversales, pour mener à bien des missions précises »[^2]

[^1]: Serge Diebolt, Le petit lexique des termes de la complexité [^2]: Wikipédia, Adhocratie [^3]: Flore Barcellini, Conception de l’artefact, conception du collectif, 2008 [^4]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^5]: Charles Antony Richard Hoare, The Emperor’s Old Clothes, 1980 [^6]: Ben Moseley, Peter Marks, Out of the Tar Pit, 2006 [^7]: Donald Knuth, Literate Programming, 1983

comportement logiciel

id : 20210221130228
dernière édition :
type : processus

Les logiciels sont par nature récursifs. Ils sont capables de faire appel et de répéter leurs propres programmes automatiquement. L’imprévisibilité de ce comportement engendre de la complexité 🔗.

L’exécution d’un programme est diachronique (se prolonge, évolue ou se transforme dans le temps[^1]). Ce n’est pas un processus continu ou même linéaire. Des opérations sont interrompues ou bien sont exécutées en parallèle (tel que prescrit dans le flot de contrôle 🔗). Elles peuvent être

  • synchrones (se produisent en même temps, ne se succèdent pas[^1]),
  • asynchrones (décalées dans le temps[^1]), comme avec l’AJAX 🔗.

On distingue la chaîne temporelle durant l’exécution du logiciel et la chaîne temporelle (asynchrone) des interactions de l’utilisateur. Ce dernier va lancer de nouvelles opérations imprévisibles dans le temps en cliquant, en remplissant des formulaires.

Modélisation

Avec la modélisation logicielle, 🔗, on tente d’effectuer une « traduction de l’évènement en document »[^2] (p.103). « les graphiques peuvent être utilisés pour présenter beaucoup plus d’informations sur l'état du programme (comme les variables et les structures de données actuelles) que ne le permettent les affichages purement textuels »[^3] (p.100) et c’est pourquoi ils sont particulièrement utiles dans la conception du comportement des programmes.

[^1]: Serge Diebolt, Le petit lexique des termes de la complexité, 2011 [^2]: Pascal Robert, Qu’est-ce qu’une technologie intellectuelle ?, 2000 [^3]: Brad Myers, Taxonomies of Visual Programming and Program Visualization, 1990

compréhension de l’API d’un logiciel

id : 20210220101744
dernière édition :
type : processus
mots-clés : REVUE

De manière générale, l’entrée dans la documentation d’un logiciel se fait par un quickstart. Ce guide de « départ rapide » permet d’obtenir rapidement une premier résultat, une base visuelle à importer dans son environnement. Elle est souvent accompagnée d’exemples élaborés par les développeurs. Ils proposent des réutilisations prêtes à être modifiées et extraites pour les intégrer dans un nouveau projet. L’utilisateur peut ainsi ignorer l’interface de programmation (API) 🔗 du logiciel.

Dans un deuxième temps, l’utilisateur est amené à utiliser son API. Il s’agit des fonctions principales pour personnaliser (plus ou moins profondément) l’utilisation qu’il a du logiciel.

Dans un dernier temps, l’utilisateur est invité à comprendre l’API. Ainsi, il peut proposer des modifications/extensions du logiciel dans une continuité.

compréhension et écriture des programmes

id : 20211018184757
dernière édition :
type : documentation

Ruven Brooks présente différentes pistes de reflexion autour de la compréhension des programmes 🔗[^1] (p.544). En fonction de la variation des critères suivants, les développeurs appréhenderaient différement le programme :

  • propriétés des calculs ;
  • longueur du fichier, langage de programmation 🔗 ;
  • l’activités du développeur (ajout, modification, suppression ou lecture de code) ;
  • la subjectivité du développeur.

L’activité de programmation conciste à « construire des mappings depuis un domaine de problème »[^1] (p.545), c’est à dire à définir les frontières, limites du domaine et dans ce cadre analyser la relation entre les personnes et les objets. Comprendre le programme conciste notamment à retrouver tout ou partie de ces limites et entités, depuis l’opération de mapping. Le développeur émet des hypothèses sur la manière dont doit être élaborée la solution au problème.

Ruven Brooks établi que pour comprendre et écrire des programmes[^1] (p.553), il faut

  • savoir programmer ;
  • connaître le domaine de résolution de problèmes ;
  • savoir élaborder une stratégie de résolutions (émettre des hypothèses).

« La traduction de l’algorithme dans un langage de programmation crée encore un autre domaine, avec des implémentations de structures de données et les opérations primitives du langage de programmation. Enfin, l’exécution du programme produit un domaine dans lequel les objets sont les contenus des emplacements mémoire et les opérations sont celles du matériel »[^1] (p.544) 🔗

« Alors qu’un programme est logiquement une structure hiérarchique, la source du programme est physiquement plate. Les compilateurs sont capables de reconstruire la hiérarchie syntaxique ; les humains ont la tâche beaucoup plus difficile de reconstruire la hiérarchie logique »[^2] (p.4)

[^1]: Ruven Brooks, Towards a theory of the comprehension of computer programs, 1983 [^2]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

computationnel

id : 20210502102039
dernière édition :
type : inscription
mots-clés : REVUE

« Computationnel » dérive de la computation qui désigne le calcul. Ainsi, l’agir de la machine informatique est essentiellement porté sur le calcul dans le domaine du

  • dénombrable, de ce qui peut être compté
  • discrétisable, de ce qui peut être combiné 🔗

configuration

id : 20210418085915
dernière édition :
type : processus
mots-clés : Samuel Goyet, Alan Turing, REVUE

La configuration détermine le comportement de la machine (le traitement et ce qui est traité) pour une exécution donnée.

« Si, à chaque étape [du calcul], le mouvement de la machine […] est complètement déterminé par la configuration, nous pouvons appeler cette machine une ‹ machine automatique › »[^1]

Il faut donc être capable de déterminer l’ensemble de leur configuration[^2] pour éviter des interventions humaines.

[^1]: Alan Turing, On Computable Numbers, with an Application to the Entscheidungsproblem, 1937 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

contrat de lecture

id : 20200724153738
dernière édition :
type : architecture
mots-clés : Jean-Michel Salaün, médiation, REVUE

C’est une théorie de Jean-Michel Salaün présentée dans son livre Vu, lu, su. Les architectes de l’information face au monopole du web (2012). Elle consiste en un triptyque de notions rendant compte d’un processus documentaire 🔗 complet.

graph TD

vu[Vu : compréhension]
su[Su : sociabilité]
lu[Lu : lisibilité]

vu ---|médiation| su
su ---|contexte| lu
lu ---|mise en forme| vu

« Un document est une trace [Vu] permettant d’interpréter [Lu] un événement passé [Su] à partir d’un contrat de lecture ».

C’est autant le rapport entre un lecteur et un auteur que celui des individus vis-à-vis de la société. Un document digne de ce nom doit en effet être annoncé à une population pour qu’elle puisse connaître son existence et décider d’y accéder.

convention de développement

id : 20210520193136
dernière édition :
type : documentation

La convention de développement est le premier document de concertation des développeurs sur le processus de développement 🔗. Elle devrait être établie avant de commencer tout projet étant donné son impact sur tous les autres documents de la documentation logicielle 🔗 : d’elle dépend les modèles, paradigmes 🔗, le nommage des variables 🔗. Elle est également visée lors des revues de code 🔗 pour être appliquée, rappelée aux membres de l’équipe.

Dans la même logique des paradigmes de programmation 🔗, il y a différentes manières d’inscrire une même implémentation, de structurer la réponse technique au cahier des charges. Par la convention de développement, l’équipe émet différentes recommandations sur le travail des collaborateurs au sein de l’environnement de développement 🔗 afin de le rendre cohérent et ainsi d’éviter l’entropie logicielle.

  • Définir le lexique utilisé dans le code source, indispensable lorsque l’on documente le code 🔗.
  • Définir les règles d’écriture du code et des paradigmes 🔗 en application.
  • Présentation de l’architecture du projet, entre les fichiers (nom de fichiers, extensions…) et en leur sein (encodage 🔗).

Il existe de nombreux guides énumérant des règles syntaxiques 🔗 ou autres bonnes pratiques de la programmation et de ses logiciels environnants.

corps de texte balisé, sémantisé, interactif

id : 20200606213253
dernière édition :
type : inscription
mots-clés : Marcello V.R

Con-texte

Avec l’écriture analogique, le sens des micro-structures du texte est suggéré par leur forme et leur contenu. On distingue un titre et une citation du corps de texte grâce à leur apparence particulière : grands caractères, exergue etc.. C’est leur attribuer une fonction de contexte, soit l’information qu’ils apportent au texte qui les entoure (sur le support) et plus généralement au document.

🔗 paradigme de l’imprimé

Dans le cadre l’écriture numérique, cette seule qualité graphique est contextuellement insuffisante. Le sens de ces micro-structures doit être explicite pour les humains, mais aussi pour les machines : il ne s’agit pas simplement d’afficher un titre, il s’agit de faire comprendre à la machine que c’est un titre et en conséquence de l’utiliser pour des usages dépassant son simple affichage et pour aller vers l’interaction documentaire.

« Ainsi, au lieu de considérer une chaîne de caractères comme un titre ou comme le nom d’un auteur et de l’exprimer comme tel, le format n’associe à cette chaîne de caractères qu’un style visuel défini par un type de caractère, une taille, etc »[^3]

« [La micro-structure du texte] était faite sur papier avec des codes graphiques (italique, guillemets, etc.) qui, aujourd’hui, n’ont plus aucun sens. Continuer de les utiliser et confondre le balisage sémantique avec le balisage graphique est un signe de profonde incompréhension de la pratique d’écriture. »[^1]

Interprétation

Par exemple pour un paragraphe balisé sémantiquement comme titre :

  • style graphique (formel) : grands caractères gras ;
  • interaction documentaire (structurelle) : référencement dans le sommaire, mise en place d’une ancre et marquage dynamique du niveau.

Dans le cas du HTML, les micro-structures du texte sont délimitées par des balises interprétées par des logiciels d’analyse syntaxique. Les balises suivantes permettent de reconnaître un titre d’un certain niveau (sémantique) :

<h1>Titre 1</h1>
<h2>Titre 2</h2>
...
<h6>Titre 6</h6>

Il y a aussi eu dans l’histoire ce ce langage des balises (désormais obsolètes) formels et non signifiantes.

<center>
Ce texte sera centré.
 	<p>Ainsi que ce paragraphe.</p>
</center>

Plasticité

Selon l’algorithme d’interprétation du fichier contenant les bases, le paragraphe balisé titre va être affecté graphiquement, mais aussi interactivement et changer de logiciel pourra modifier tout ou partie de ces affectations. C’est la plasticité de l’écriture numérique 🔗 dont le contenu est abstrait et systématiquement (re)interprété.

Changer de logiciel c’est aussi changer les modalités d’écriture et notre perception du sens, de la forme du texte.

🔗 interfaces d’écriture

Parsing

Dans les pratiques de l’écriture numérique 🔗, une citation n’est pas une série de lignes, mais une base de données avec différents champs : auteur, titre, éditeur, date, etc.. Procéder ainsi c’est permettre à un algorithme de rassembler les références autrement que par le parsing 🔗, soit un découpage du texte pour le réinterpréter, le sémantiser. C’est là une pratique incertaine, mais nécessaire quand un travail de recherche sur le sens et l’expression n’a pas été abouti.

« les dynamiques actuelles s’articulent autour de l’introduction d’écritures possédant une sémantique formelle, c’est-à-dire permettant des calculs interprétatifs explicites plutôt que des calculs implicites encapsulés dans les logiciels traitant les données issues des écritures des utilisateurs »[^2]

🔗 base de données

[^1]: Marcello V.R., Les chercheurs en SHS s’avent-ils écrire ?, 2018 [^2]: Michael E.S. et Marcello V.R., Pratiques de l’édition numérique, 2014 [^3]: Marcello V.R, Nicolas Sauret, Antoine Fauchier, Margot Mellet, Écrire les SHS en environnement numérique. L’éditeur de texte Stylo, 2020

critères de qualité logicielle

id : 20200522111759
dernière édition :
type : processus

Il faut s’attendre à ce que le projet évolue, à ce que des fonctionnalités soient modifiées, ajoutées, supprimées. Ainsi, il faut veiller à architecturer un logiciel de manière à obtenir un système combinatoire 🔗. Pour cela on admet 16 critères.

Si l’architecture logicielle 🔗 n’est pas suffisante, on s’expose au risque de dégradation, ou entropie logicielle : déstabilisations répétées de la structure du logiciel que les corrections ne feront que repousser pour un retour toujours plus violent.

🔗 dette technique

Critères

Source : Wikipédia, Architecture logicielle

  • interopérabilité extrinsèque exprime la capacité du logiciel à communiquer et à utiliser les ressources d'autres logiciels comme les documents créés par une certaine application.
  • interopérabilité intrinsèque exprime le degré de cohérence entre le fonctionnement des commandes et des modules à l'intérieur d'un système ou d'un logiciel.
  • portabilité exprime la possibilité de compiler le code source et/ou d'exécuter le logiciel sur des plates-formes (machines, systèmes d'exploitation, environnements) différentes.
  • compatibilité exprime la possibilité, pour un logiciel, de fonctionner correctement dans un environnement ancien (compatibilité descendante) ou plus récent (compatibilité ascendante).
  • validité exprime la conformité des fonctionnalités du logiciel avec celles décrites dans le cahier des charges.
  • vérifiabilité exprime la simplicité de vérification de la validité.
  • intégrité exprime la faculté du logiciel à protéger ses fonctions et ses données d'accès non autorisés.
  • fiabilité exprime la faculté du logiciel à gérer correctement ses propres erreurs de fonctionnement en cours d'exécution.
  • maintenabilité exprime la simplicité de correction et de modification du logiciel, et même, parfois, la possibilité de modification du logiciel en cours d'exécution.
  • réutilisabilité exprime la capacité de concevoir le logiciel avec des composants déjà conçus tout en permettant la réutilisation simple de ses propres composants pour le développement d'autres logiciels.
  • extensibilité exprime la possibilité d'étendre simplement les fonctionnalités d'un logiciel sans compromettre son intégrité et sa fiabilité.
  • efficacité exprime la capacité du logiciel à exploiter au mieux les ressources offertes par la ou les machines où le logiciel sera implanté.
  • autonomie exprime la capacité de contrôle de son exécution, de ses données et de ses communications.
  • transparence exprime la capacité pour un logiciel de masquer à l'utilisateur (humain ou machine) les détails inutiles à l'utilisation de ses fonctionnalités.
  • composabilité exprime la capacité pour un logiciel de combiner des informations provenant de sources différentes.
  • convivialité décrit la facilité d'apprentissage et d'utilisation du logiciel par les usagers.

CSS, Cascading Style Sheets

id : 20200704152459
dernière édition :
type : programmation
mots-clés : technique

Le CSS (Cascading Style Sheets) est un langage permettant d’inscrire une feuille de style 🔗 utilisée pour décrire la présentation d’un document inscrit en HTML : apparence, position et réaction des objets qui le composent.

Sélection, règles et portée

Cascade

Selon le principe de cascade de ce langage, il faut retenir trois variables en CSS :

  • le niveau de spécificité des sélecteurs ;
  • la précision des règles ;
  • la portée des sélecteurs.

Ainsi, la spécificité des sélecteurs et des règles doivent être progressives : plus un sélecteur est lourd, spécifique, plus il doit être bas (déclaré tardivement) et peut affecter des règles précises.

Voici les différents sélecteurs, rangés selon leur poids. Il faut ajouter que l’opération de combinaison (ex : ul li.imp-elt[data-active="true"]) de ces sélecteurs ajoute du « poids » :

  1. étoile : *, portée maximale
  2. balise : p
  3. classe : .btn
  4. attributs : [data-type="circle"]
  5. identifiants : #main, portée unitaire

L’étoile, le :root, le html doivent être déclarés en premier et affecter des règles très générales (portant sur la totalité des éléments), tandis que les identifiants sont déclarés en dernier et portent des règles spécifiques à un élément :

* { box-sizing: border-box; }
…
#btn-volet-close {
    position: absolute;
    top: 4px;
}

Sélecteurs combinatoires

Les sélecteurs CSS (également utilisables en JavaScript avec les méthodes querySelector et querySelectorAll) permettent d’appréhender les relations de l’espace du DOM 🔗, entre les balises :

  • parent : vis-à-vis d’une balise qu’elle encapsule ;
  • enfant : se dit d’une balise encapsulée ;
  • frère : relation de balises adjacentes, encapsulées au même niveau.

Ci-dessous des exemples de code mettant en pratique ces relations :

p p { /* tous les p encapsulés dans (enfants de) un p */ }
p > p { /* tous les p enfants directs (sans encapuslation intermédiaire) d’un p */ }
p ~ p { /* tous les p adjacents (frère de) d’un p */ }
p + p { /* le premier p adjacent (frère de) d’un p */ }

/* pseudo-classes */
p:first-child { /* tous les p qui sont premiers éléments encapsulés (enfants) de leur parent */ }
p:last-child { /* tous les p qui sont derniers éléments encapsulés (enfants) de leur parent */ }
p:first-of-type { /* tous les p qui sont premiers éléments encapsulés (enfants) de ce type au sein de leur parent */ }
p:last-of-type { /* tous les p qui sont derniers éléments encapsulés (enfants) de ce type au sein de leur parent */ }
p:nth-child(odd) {}
p:nth-of-type(even) {}

SCSS

Le SCSS et le Less sont des langages de programmation transpilés 🔗 en CSS et permettent d’optimiser son inscription (avec la convention BEM 🔗). Ils permettent de sélectionner les objets et d’affecter les règles via différents systèmes :

  • inclusions (@import : importe toutes les déclarations d’un fichier)
  • extensions (@extend : importe les règles affectées à un sélecteur)
  • tableaux
  • mixins (@mixin : génère des règles selon des paramètres d’entrée)
  • boucles (@each)
  • conditionnelles (@if, @else)

cycle de développement logiciel

id : 20210306102014
dernière édition :
type : processus
mots-clés : projet

Le cycle de développement d’un logiciel couvre tout le long de sa « vie ». Il débute à l’instant où jaillit l’idée du logiciel et prend fin à l’abandon du projet (« mort » du logiciel). Entre temps, il couvre plusieurs périodes, et notamment celle de maintenance 🔗. Chacune de ces étapes de ce cycle vient enrichir la documentation du logiciel 🔗 avec la description des expériences vécues et des décisions prises.

Il existe plusieurs diagrammes 🔗 pour représenter le cycle du développement d’un logiciel. On distingue les linéaires des itératifs.

Représentations linéaires

Elles proposent d’imaginer le développement d’un logiciel comme une succession d’étapes (jalons) sur une longue période.

Source : https://web.maths.unsw.edu.au/~lafaye/CCM/genie-logiciel/cycle-de-vie.htm

« en cascade »

De cette représentation on retient la nécessité de vérifier systématiquement le travail effectué. Il s’effectue en différentes étapes :

  1. spécifications 🔗 : élicitation, description fonctionnelle (quoi et comment) de chaque artefact sur la base de besoins donnés ;
  2. conception générale : définition de l’environnement de développement 🔗 et architecture du logiciel 🔗; divisé en modules 🔗[^2] (p.1) ;
  3. conception détaillée : modélisation 🔗 des modules afin d’optimiser le traitement ;
  4. programmation : implémentation 🔗 ;
  5. tests unitaires 🔗 : test des modules 🔗 du logiciel ;
  6. intégration : interfacer les modules 🔗 développés ;
  7. qualification/recette : vérification de la conformité du logiciel par rapport aux spécifications ;
  8. mise en production : publication, mise en place du logiciel pour usage ;
  9. maintenance : amélioration/adaptation du logiciel à son environnement, ses usagers.

« en V »

De cette représentation on retient le besoin d’anticiper les méthodes et critères de validation, d’évaluation, et ce dès la conception. Ainsi, on met en rapport les étapes suivantes issues du diagramme précédent :

  • 1 (spécifications) → 7 (qualification/recette)
  • 2 (conception générale) → 6 (intégration)
  • 3 (conception détaillée) → 5 (tests unitaires)

« en spirale »

De cette représentation, plus orientée vers la gestion de projet, on retient que la majorité du temps de travail de développement logiciel est dédié à la spécification (1) ; à l’échange avec l’usager pour l’expression de ses besoins et leur traduction technique. Cela passe par l’idéation et le développement d’une série de prototypes (réalisations intermédiaires) après lesquels on prendra le temps de réviser la conception générale (2). C’est dans un dernier élan que l’on enchaîne les autres étapes (3 → 9).

Représentations itératives

On entend généralement que la construction de logiciels est comme la construction de bâtiments, nous ne pouvons pas faire cela tant que les fondations ne sont pas en place[^2]. Le cycle de développement logiciel 🔗 impose en effet d’effectuer les tâches de conception en cascade, par couche successive ; autant de briques sans lesquelles l’édifice de tient pas.

La différence entre un cycle agile et non-agile se situe dans la répétition du cycle. On planifie le travail sur une ou deux semaines plutôt que sur des mois. Les temps de spécification (1) et de qualification/recette (7) sont répétées sur des courtes périodes pour s’adapter à une navette rapide entre l’usager et l’équipe de développement selon les méthodes des projets agiles 🔗.

Développement agile

Il faut attendre la fin d’un cycle pour obtenir un produit avec une valeur commerciale. La procédure linéaire n’accorde aucune valeur au logiciel avant sa totale production. La procédure agile apporte peu à peu de la valeur au logiciel.

Extreme Programming

L’Extreme Programming (XP) est une méthode de gestion de projet logiciel poussant à l’extrême les idées du management de projet logiciel. Elle est particulièrement exigeante, à la fois humainement et techniquement. Les nerfs peuvent être mis à rude épreuve, et la cohésion, le respect des personnes et du travail bien fait sont essentiels. Cette modalité de travail est adaptée à des équipes de 2 à 10 développeurs[^2] (p.2)

Les sprints sont rapides avec un échange très régulier entre le commendataire (« partie intégrante du projet »[^2], p.2) et les développeurs. On insiste sur les principes suivants :

  • assurer la qualité du code avec le pair programming et la revue de code 🔗 systématiques, quitte à devoir réécrire régulièrement des pans entiers de code source pour soigner les métaphore et conserver une conception simple pour compenser la dette technique 🔗 ;
  • besoin d’un retour régulier et assuré sur les fonctionnalités avec le développement piloté par test 🔗 et l’intégration systématique de fonctionnalités stables. Cette suite de test « communiquant ainsi, d’une certaine manière, l’intention du logiciel »[^2] (p.2).

L’Extreme Programming insiste également sur la simplicité de l’implémentation en ne consacrant pas de temps à la mise en place de supports pour des fonctionnalités qui ne sont pas certaines. On supporse qu’une application simple et soignée pourra de toute manière évoluer avec fluidité.

« une attitude de changement constant des exigences et l’affinement de la conception devient alors possible. Il n’est pas nécessaire de disposer de modèles et de documents d’analyse et de conception préalables »[^2] (p.2)

Limites de la communication orale

L’Extreme Programming néglige la documentation du logiciel 🔗. Elle fait le pari qu’avancer progressivement sur des fondations saines et réévaluer en permanence l’ouvrage permet de concevoir un édifice suffisemment stable pour être maintenu 🔗 sans documentation[^2] (p.2). Or, « Comment faire pour affiner ce qui n’est pas documenté ? »[^2] (p.2), comment s’assuer que les spécifications 🔗 seront bien analysées et modélisées 🔗 ? « La suite de tests est-elle vraiment un substitut à cet égard ? […] Les suites de tests et la communication communication orale suffisent-elles à garantir que tous les membres de l’équipe ont un contrôle intellectuel sur la conception ? »[^2] (p.2). Ainsi, l’architecture logicielle 🔗 se réaffirme comme un rapport social, qui ne saurait être uniquement oral.

[^1]: Josh Gough, Agile Software Construction is Like Neighborhood Construction, 2009 [^2]: Lionel Briand, Software documentation: how much is enough?, 2003

démonstration de fonctionnement du code

id : 20210625125642
dernière édition :
type : documentation

Comme tout utilisateur, un développeur a besoin lorsqu’il utilise un programme d’obtenir rapidement un premier résultat pour l’encourager à poursuivre son utilisation et ainsi valider l’intérêt qu’il a pour le programme. Depuis la documentation, il pourra obtenir une commande ou un lien pour installer le programme, ainsi que quelques lignes de code à inscrire pour obtenir une première interaction avec lui. Typiquement, afficher « Hello world! ».

Test en direct

Certaines documentations logicielles 🔗 proposent des fenêtres de test (intégrant un code source exemple) adossées à une fenêtre de rendu pour nous faire une démonstration de ce que peuvent rendre quelques lignes de code. Animées par des outils comme CodeMirror nous permet de voir en direct le résultat de nos modifications depuis ces fenêtres de test. Ainsi, on peut avoir une démonstration sans avoir à installer le programme.

Programmes complexes

Certains programmes sont trop complexes 🔗 pour être introduits en quelques exemples. Il faudrait d’abord que le développeur se familiarise avec les différents modules 🔗 à maîtriser, leur interfaçage.

Utilisation dictée par l’architecture

Ces programmes qu’il est difficile d’aborder sont peu abstraits 🔗. Ils ne permettent de faire appel à un modèle (ex : une classe permettant de générer un graphe) qui va lui-même appeler tout les modules correspondants (ex : à partir d’un jeu de données, génération des nœuds et liens, spacialisation, activation des intéractions avec la souris…). Il va au contraire demander à ce que le développeur-utilisateur seul fasse appel à ces différents modules en respectant la chaîne du traitement des données (ex : d’abord sérialiser les données, puis générer les nœuds, puis les spatialiser…). Ce qui lui laisse la pleine maîtrise du flot de contrôle 🔗 et la responsabilité de ses erreurs et de sa documentation. Ces contraintes sont la preuve que la méthode d’apprentissage, d’utilisation du logiciel par le développeur dépend de son architecture 🔗.

« La plupart des utilisateurs de systèmes informatiques ne prêtent guère attention aux instructions et font plutôt des hypothèses provisoires sur le fonctionnement du système. Souvent, ces hypothèses s’avèrent fausses lorsque le système ne se comporte pas comme prévu. Les utilisateurs doivent alors modifier leurs hypothèses de travail (leur modèle mental) »[^1] (p.50)

Un programme plus abstrait 🔗 permettrait au contraire au développeur-utilisateur d’obtenir un résultat plus facilement, rapidement. Toutefois, il perdrait en contrôle, ne pourrait pas disposer des instructions intermédiaires pour adapter le programme à son usage. Ces architectures austères, plutôt que de conforter le développeur-utilisateur dans la vision faussée qu’il a du fonctionnement du programme, avec la possiblité pour le développeur d’éviter des erreurs qu’il ne pourrait corriger.

« Les systèmes qui permettent à l’utilisateur de corriger facilement ses erreurs donnent à l’utilisateur un fort sentiment de contrôle. Il est préférable de faciliter la correction des erreurs plutôt que de les rendre difficiles à commettre. »[^1] (p.50)

Documentation

Pour un tel mode d’apprentissage, la documentation prend une distance particulière. Elle ne peut être suffisamment efficace pour accompagner le développeur hâté et va donc rester en support, en arrière plan. On va donner à l’utilisateur-développeur une série de code source exemples qu’il va pouvoir tester. La documentation (notamment grâce à l’index de l’API 🔗) va fournir des explications sur les éléments de ces exemples pour aider les utilisateur-développeurs les plus pointilleux.

Le développeur-utilisateur va rencontrer de nombreuses erreurs, éprouver la vision qu’il avait du fonctionnement du programme. Les messages d’erreur 🔗 renvoyés par le programme sont alors une part importante de la documentation du programme. Elles vont lui permettre de trouver des pistes de recherche complémentaires et ainsi de perfectionner son utilisation.

[^1]: Wiliam Horton, Designing & writting online documentation, 1990

démonstration du code

id : 20210906111350
dernière édition :
type : documentation

Documenter le code 🔗 ne suffit pas à informer l’utilisateur de la portée hypertextuelle de l’environnement de développement 🔗 dans lequel il est intégré. Chaque ligne de code peut nécessiter des phrases entières pour expliciter (comme le prescrit le paradigme de la programmation lettrée 🔗) l’incidence…

  • des choix du développeur ;
  • de la programmation de ces entités et de celles dont elles dépendent.

Hors les commentaires de code 🔗 ne permettent pas de faire de lien hypertexte. Il est nécessaire d’utiliser un EDI 🔗 pour obtenir une mise en forme des annotations (panneau contextuel au survol, interprétation du Markdown 🔗…) tandis que leur configuration varie. Ces mêmes annotations ne peuvent pas prendre trop d’espace dans les fichiers quand bien même il y aurait beaucoup à présenter.

Ainsi, il faut un dispositif complémentaire.

Cas

La documentation de Strapi est exemplaire. Elle permet de comprendre chaque extrait de code sous tous les axes (ci-dessous) et de faire un véritable parallèle entre le code source et sa documentation.

  • environnement de développement 🔗 (plateforme, langage de programmation utilisé, version utilisée…)
  • temporel (quels échanges de requêtes 🔗 asynchrones ?)
  • spatial (dans quels fichiers ?)
  • fonctionnel (comment ça devrait réagir ?)
  • explicatif (comment ça a été conçu, pourquoi ?)
  • vertical (quelle instruction prescrit telle portion de code ?)
  • horizontal (quelles dépendances, incidences ?)
  • modification (comment modifier ?) via un formulaire 🔗 pour compléter permettant de compléter un code valide

Les tutoriels reposent entièrement sur un code source exemple. L’affichage est divisé en deux parties attenantes. Celle de gauche comporte le tutoriel (prose répartie en sections) et celle de droite comporte le code source exemple (segmenté par ligne de code). Le code source exemple est répartis sur plusieurs fichiers et varie selon l’environnement de développement de l’usager.

Certaines portions du code source disposent d’une bulle d’aide pour délivrer des informations supplémentaires sur la définition, la valeur ou d’autres caractéristiques de la variable 🔗.

Le code source est filtré par une vue 🔗. Les portions de code pertinentes (selon la section du tutoriel consultée par le lecteur) sont surlignées dans le fichier pertinent. Au fur et à mesure que l’on fait défiler le tutoriel, qu’il évoque d’autres instructions (à comprendre pour les modifier) prescrites par le code source exemple, c’est une autre portion du code source qui est surlignée, éventuellement dans un autre fichier.

Ils proposent des formulaires permettant de modifier le code source exemple (ex : modifier la couleur du bouton, ajouter un champ supplémentaire). Ainsi, les modifications apportées sont contrôlées et valides, limitant les erreurs de l’utilisateur. De plus, le tutoriel (en miroir du code) s’allonge de quelques sections pour expliquer ces ajouts.

dépendances logicielles

id : 20200701083222
dernière édition :
type : architecture
mots-clés : technique, REVUE

🔗 modularité logicielle

Les dépendances logicielles sont des modules externes à l’architecture du développeur ou de l’utilisateur. Le développeur les ajoute à son architecture pour ajouter des fonctionnalités à son programme sans avoir à les développer.

Architecture

L’enjeux du développeur est de garder un système souple et robuste, de décentraliser les efforts et les risques. Ainsi en recourant à des dépendances :

  • on évite de reproduire un élément qui a déjà été développé et vérifié ;
  • on évite les failles globales en isolant les composants : on risque des failles locales et/ou structurelles.

« tout l’enjeu n’est pas de nier nos dépendances mais de les choisir en connaissance de cause »[^1]

Les dépendances type bibliothèque de code 🔗 vont permettre d'ajouter des fonctionnalités tandis que les frameworks permettent de mettre en place une architecture pour les différents processus.

🔗 framework ou cadriciel

Il existe aussi les middleware (aussi appelés « intergiciel »), soit des logiciels tiers permettant de traiter le flux d’information entre deux autres programmes. Ce sont des dépendances pouvant être remplacées par l’utilisateur.

Sentier de dépendances

Le risque est l’endettement technique 🔗 et ses nombreuses conséquences à différents endroits : architecture interne (code spaghetti, cohabitation de différentes architectures etc.) et externe (accessibilité, longueurs dans les chargements etc.).

🔗 site web lowtech

L’informatique repose entièrement sur des dépendances à tel point que l’on parle de « couches logicielles », soit des dépendances basées sur des centaines de dépendances.

🔗 API, interface de programmation

Temps

Une grande parties des codes source — et donc leur sous-couches, extensions et dépendances — sont gratuits, maintenus par des bénévoles. Le temps joue irrémédiablement sur les dépendances, version après version.

🔗 logiciel libre et logiciel open source

Il est très important de connaître la version d’une dépendance dès qu’on l’intègre dans un environnement : la travail de développement étant asynchrone entre les deux projets, les fonctions, l’API peuvent rapidement changer. On parle de version mineures pour des corrections et majeures pour l’ajout de fonctionnalités tel qu’il peut entraîner des bugs dans un programme conçu sous une version antérieure.

[^1]: Arthur Perret, Pour un autre carnet de recherche numérique, 2019

dette technique

id : 20210109130329
dernière édition :
type : architecture
mots-clés : projet

La dette technique est l’ensemble des coûts cachés et nécessaires dus à la complexité montante d’un projet logiciel suivant les choix de conception et de construction diminuant la rentabilité d’un logiciel[^1]. L’incohérence d’un programme, un code source trop complexe ou écrit maladroitement sont une perte de temps considérable. Cette perte d’énergie est due à l’entropie, la tendance naturelle d’un système à se désordonner.

La dette s’accumule à mesure que le développement progresse et le debugage est d’autant plus complexe. Naturellement, cette entropie va monter au fur et à mesure de la vie du logiciel et les coûts de maintenance 🔗 vont augmenter en conséquence. On parle d’« érosion de l’architecture logicielle »[^1]. Mais ça n’est pas une fatalité. Les ingénieurs sont là pour prévenir ces risques.

La dette technique est un choix et s’anticipe : on a pas le temps de concevoir une fonctionnalité avec suffisamment de finesse et on va donc décider d’augmenter la complexité du logiciel pour obtenir plus rapidement un résultat. Toutefois, avant de faire cela, il faut se demander si on a le temps de refactoriser 🔗 ce programme par la suite. Cela revient à se demander si l’on a le temps de développer le programme une seconde fois, pour rembourser la dette[^2].

Une dette technique non anticipée et subie est une pourriture logicielle[^2].

Chute exponentielle

Selon les lois décrites par Manny Lehman 🔗, un système informatique se doit d’évoluer en permanence pour s’adapter à son environnement, sinon il deviendra progressivement de moins en moins utile dans cet environnement. En effet, les attentes des utilisateurs augmentent. Comme le logiciel est modifié régulièrement, il devient plus en plus complexe (qualité moindre), à moins d’endiguer ce processus. On se rend compte bien tard en général que le projet est devenu trop important sans que les concepteurs et outils n’aient été adaptés.

La complexité d’un logiciel est exponentielle. Tout logiciel a une complexité essentielle qui le précède, une complexité obligatoire découlant du cahier des charges et enfin une complexité accidentelle[^2]. Cette dernière doit être réduite au maximum.

Ainsi, prévenir la dette technique ne doit pas paraître comme un investissement inutile, n’apportant aucune fonctionnalité supplémentaire, consommant inutilement du temps. Au contraire, il faut prendre sérieusement en compte ce risque qui peut conduire à de gros retards, voire à un échec du projet, un arrêt du développement.

Lutter contre l’entropie

Il faut sensibiliser et former les développeurs à anticiper la dette technique engendrée par leur travail. Un code mal écrit n’appelle pas autre chose que plus de code bâclé ; les développeurs pourraient ne pas faire d’effort. Au contraire, un code source excellent appelle à la vigilance. Par conséquent, il faut régulièrement faire une revue de code et ainsi assurer sa qualité, pointer et corriger les dégradations.

« La duplication de code étant l’un des facteurs accélérant le plus l’entropie logicielle », il faut régulièrement faire du refactoring 🔗 pour qu’il reste maintenable.

[^1]: Arnaud Lemaire, L’entropie logicielle, pourquoi la dette technique ne fait qu’augmenter ?, 2014 [^2]: Arnaud Lemaire, Dette Technique Et Entropie Logicielle, 2018

développement piloté par tests

id : 20210525213204
dernière édition :
type : programmation
mots-clés : projet

🔗 test logiciel

Le développement piloté par tests (Test-Driven Development, TDD) est une méthode de développement selon laquelle on va diriger l’inscription du code du logiciel avec des tests automatiques. Cette technique méticuleuse permet de produire un code très robuste, puisque on construit pas à pas des tests unitaires (permettant de valider le fonctionnement de chaque module 🔗) évitant ainsi la régression, la perte du support de certaines fonctionnalités dû à des effets de bord 🔗 préjudiciables et non surveillés.

Méthode

Généralement lorsque l’on implémente un algorithme, on inscrit le code de fonctionnement, puis (pas toujours…) le code de test lié à cette fonctionnalité. Le test découle du code ; le TDD inverse ce processus. On inscrit le code du test, puis le code qui va respecter le test. Cette deuxième méthode force le développeur à penser son test sur-mesure pour le code qui va devoir être validé. Ce même code qui aura été savamment conçu alors que l’on a longuement réfléchit aux erreurs qu’il pouvait causer.

Le code est ainsi inscrit en cinq étapes :

  1. Inscrire une série de tests en vérifiant que chacun échoue, faute de code valide
  2. Inscrire un code valide et le tester
  3. Refactoriser 🔗 le code pour qu’il soit simple et clair.

C’est une approche didactique que l’on retrouve dans la programmation lettrée 🔗. Elle impose comme avec ce paradigme d’exprimer et justifier longuement les choix techniques. Ces choix sont matérialisés par des tests qui, commentés, informent le lecteur sur le format des données qui sont traitées.

diagramme

id : 20210117165423
dernière édition :
type : modélisation
mots-clés : Yves Jeanneret

🔗 visualisation

Un diagramme est une vue simplifiée 🔗 et géométrique d’une situation complexe. Il représente des parties d’un ensemble et impose une représentation partielle du phénomène à ses lecteurs. Ils projettent « un regard à la fois impérieux et impossible »[^1] sur une composition générée à partir d’une variété de données. Pour cela ils doivent accepter de se détacher du contexte et de se plonger dans une accumulation d’informations : « l’abstraction totale du regard et la concrétisation totale du réel »[^1].

Composition

Yves Jeanneret énumère[^1] ainsi les composants des diagrammes, soit des compositions « techno-sémiotique », comme « une forme de la raison graphique » 🔗 :

  • l’écriture (calibrage et alignement des signes) ;
  • la liste (mise en série des unités) ;
  • le tableau (sémantisation des deux dimensions du plan) ;
  • la carte (rabattement sur les deux dimensions d’un plan d’un phénomène multidimensionnel).

Dessin

Yves Jeanneret commente les cercles présents sur un diagramme en exemple :

« la complétude et l’indépendance sont exprimées par le cercle, forme universelle et atomiste »[^1]

Partialité

« tout en exposant un discours fait de visibilité et d’évidence, il [le diagramme] en masque l’histoire et la genèse »[^1]

« En devenant forme, le sens éloigne sa contingence ; il se vide, il s’appauvrit, l’histoire s’évapore, il ne reste plus que la lettre »[^2]

[^1]: Yves Jeanneret, Yves Chevalier, La physionomie des systèmes : diagrammes et représentation, 2009 [^2]: Roland Barthes, Mythologies, 1957

DigComp, évaluation des compétences numériques

id : 20201002103853
dernière édition :
type : processus
mots-clés : projet, politique

En 2017, la Commission européenne présente un rapport sur l’apprentissage des outils numériques comme un processus en plusieurs étapes, passant par différents niveaux, et avec pour finalité l’insertion professionnelle, l’inclusion sociale et l’épanouissement personnel dans le milieu numérique.

Nous parlons d’aptitudes, de potentiels à activer des citoyens en vue de devenir capable de s’emparer d’un certain nombre de tâches, de développer des compétences, voire des méta-compétences (compétences permettant d’en développer de nouvelles) et ainsi de gérer la complexité 🔗 de ce domaine.

Compétences

Pour cela, le rapport défini 21 compétences numériques (réparties sur 5 catégories) que doivent développer les citoyens :

  • Littératie de l’information, des données et contenus numériques :
    • Navigation, recherche et filtrage ;
    • Évaluation ;
    • Gestion ;
  • Communication et collaboration :
    • Interaction ;
    • Partage ;
    • Engagement citoyen ;
    • Collaboration ;
    • Netiquette (e-réputation) ;
    • Gestion de l’identité ;
  • Création de contenus numériques :
    • Conception ;
    • Intégration et réélaboration ;
    • Droits d’auteur et licences ;
    • Programmation ;
  • Sécurité :
    • Connaissances des dispositifs ;
    • Protection des données personnelles et de la vie privée ;
    • Protection de la santé et du bien-être ;
    • Protection de l'environnement ;
  • Résolution de problèmes :
    • Résoudre les problèmes techniques ;
    • Identifier les besoins et les réponses au problèmes ;
    • Utiliser les technologies numériques de manière créative ;
    • Identifier les lacunes en matière de compétences numériques.

Niveaux

La rapport distingue une progression en 8 niveaux (réparties sur 5 sections) :

  • Fondamentaux :
    • Niveau 1 : J’ai besoin d’aide pour trouver les informations dont j’ai besoin, l’accès et pour adopter une stratégie de navigation :
      • Quoi : Tâches simples,
      • Comment : Avec guidage,
      • Qui : Une apprenante constante ;
    • Niveau 2 : J’ai parfois besoin d’aide pour trouver les informations dont j’ai besoin, l’accès et pour adopter une stratégie de navigation :
      • Quoi : Tâches simples,
      • Comment : En voie d’autonomie avec un guidage au besoin,
      • Qui : Une apprenante régulière ;
  • Intermédiaire :
    • Niveau 3 : Seule, j’ai trouvé une routine pour récupérer les informations dont j’ai besoin. Je peux les expliquer, leur accès et ma stratégie de navigation :
      • Quoi : Tâches quotidiennes et résolution de problèmes routiniers,
      • Comment : Autonome,
      • Qui : Elle comprend ce qu’elle fait ;
    • Niveau 4 : En fonction de mes besoins qui peuvent varier, je peux illustrer mes besoins en information et mon environnement numérique, en décrire l’accès et la stratégie de navigation adoptée :
      • Quoi : Tâches parfois nouvelles et résolution de problèmes nouveaux,
      • Comment : Autonome dans son domaine,
      • Qui : Elle comprend son domaine ;
  • Avancé :
    • Niveau 5 : En plus de guider les autres je peux rechercher, accéder et naviguer dans des environnements numériques nouveaux avec une stratégie de recherche personnelle :
      • Quoi : Variété de tâches et problèmes,
      • Comment : En guidant les autres,
      • Qui : Elle adapte ses connaissances ;
    • Niveau 6 : Je peux évaluer mes besoins et ceux des autres, adapter ma stratégie de recherche et finalement choisir les informations les plus appropriées de la récolte :
      • Quoi : Choix des meilleures tâches,
      • Comment : Adapter l’environnement d’autres utilisatrices dans un domaine complexe,
      • Qui : Elle évalue ;
  • Hautement spécialisé :
    • Niveau 7 : Hautement spécialisée, je peux conceptualiser et intégrer des solutions à des problèmes complexes liés à la récolte, le filtrage, l’accès et la navigation :
      • Quoi : Résolution de problèmes avec un nombre limité de solution,
      • Comment : Contribution et aide dans un cadre professionnel,
      • Qui : Elle est créative ;
    • Niveau 8 : Au plus haut niveau de spécialité, je peux résoudre des problèmes complexes car aux nombreux facteurs d’interaction et proposer un processus-solution :
      • Quoi : Résolution de problèmes complexes (nombreux facteurs),
      • Comment : Proposition de processus et méthodes dans un domaine,
      • Qui : Elle est créative ;

Pour accéder aux niveaux 7 et 8, il faut accepter de ses limiter à un domaine. En effet, la documentation de solutions à des problèmes (complexes, au niveau 8) demande de prendre en compte les contraintes d’un domaine particulier.

On remarque que la recherche d’information telle qu’elle est décrite pour les différents niveaux retombe toujours sur le même cycle :

  1. Définition de l’information recherchée
  2. Accès aux données et contenus
  3. Stratégie de navigation 🔗 dans la base
  4. Filtrage des informations (acquis au niveau 6)
  5. Intégration de la solution (acquis au niveau 7)

digital labor

id : 20200705114827
dernière édition :
type : processus
mots-clés : politique, Antonio Casili

🔗 travail gratuit, économie du web de plateforme

Le travail sur le web, globalement collectif, a son pendant individuel. Il est récemment « devenu possible de penser les activités des internautes comme un travail individualisé et finalisé et de déployer un autre dispositif, celui du digital labor »[^1] (p.64)

Déséquilibre

Les « Activités rémunérées et bénévoles cohabitent depuis les premiers pas du réseau » mais elles entretiennent depuis quelques années un « rapport de force […] transformé et inversé avec la massification du web et la prise du pouvoir des acteurs économiques dans les zones de haute visibilité du web »[^1] (p.65)

Selon Dominique Cardon, cela tient à trois facteurs[^1] (p.65) :

  • Déséquilibre marchand
  • Calcul de réputation
  • Micro-évaluation macrophage du travail

Déséquilibre marchand

Le reversement s’est fait quand les plateformes ont vu que les pages individuelles ne leur rapportaient pas suffisamment de visiteurs et qu’elles ont donc ambitionné de centraliser l’activité des internautes. Ainsi, sur Facebook il est possible de s’y enquérir

  • de l’actualité (international, sport, culture… );
  • de la vie de ses proches ;
  • de se divertir ;
  • de prolonger cette activité d’agrégation par le biais des messages privés.

Ainsi l’expérience web de nombreux internautes se limite à un ou deux réseaux. Ajoutons à leurs habitudes d’utilisation Instagram (racheté par Facebook), centré sur le partage de photo et vidéos, et des millions d’internautes se retrouvent, sinon entièrement, en grande partie dépendants des algorithmes de Facebook.

Dans la même idée, Amazon agrège des sites marchands, si bien qu’une très grande parties des achats du monde passent pas ses voies. Enfin, le plus grand : Google est notre second cerveau, rien que ça.

Calcul de réputation

« [L’économie de la réputation] ne cherche plus à étendre le tissu de dettes mutuelles entre internautes, mais à calculer une valeur qui les singularise et les distingue les uns des autres »[^1] (p.67)

Les réseaux sociaux ont implanté des outils métriques de réputation (e-réputation, netiquette) favorisant ainsi la création de contenu, motivée par l’augmentation de ces chiffres à la face des autres internautes.

Micro-évaluation macrophage du travail

On estime le travail d’un développeur, d’un graphiste non pas sur le tout de son œuvre, cela serait trop compliqué (et dépend principalement des interfaces auxquelles nous avons accès), mais sur des unités, des mots-clés, une interface. Si le tout est supérieur à la sommes de ses particules, alors on comprend pourquoi le micro-travail est si malsain pour nos métiers et tend à le travestir.

Ainsi, le tout n’est plus que du ressort des agrégateurs qui gardent et nourrissent les intelligences artificielles qui leur permettent de mieux en mieux de considérer ce tout qu’ils revendent en particules sur des interfaces. Du côté des algorithmes, le travail s’affine, du côté des interfaces il se banalise en chiffres, graphiques, mots-clés.

Ce sont ces particules qui favorisent un travail continu car marchandable. Ce travail entraîne les algorithmes qui fournissent de meilleures particules, bouclant la boucle.

Exemple : Le graphiste produit des contenus qu’il affiche sur son Behance. Sur l’interface on affiche ses outils, le nombre de projet, de commentaires, de likes. Face à cette interface le graphiste souhaite davantage valoriser son travail et va donc ajouter des projets, s’investir socialement (travail cognitif) pour obtenir plus de commentaires, de likes. Du côté des algorithmes, on analyse les commentaires, positifs ou négatifs, on dresse un portrait du travailleur en « agrégeant/transsubstantisant »[^2] des contenus d’autres plateformes qu‘il fréquente (facile, il les a relié à sa page Behance pour faciliter son travail social) : est-ce qu’il est en relation avec d’autres graphistes ? Quelles sont leurs statistiques, leur profil ?

Où sont les interfaces qui affichent de tels résultats et qui peut y accéder ? Combien paieraient un recruteur pour embaucher par pur espionnage ?

Travail

Selon Antonio Casili, l’activité de créateur de contenus (interactions, tweet, commentaire, article de blog, partage de code etc.) est assimilable au travail (invisible et invisibilisé pourtant réel, non qualifié, gratuit, contrôlé et exploité) parce que « productrices de valeurs, faisant l’objet d’un quelconque encadrement contractuel et soumises à des métriques de performance » :

  • productrices de valeurs : contenus (photos, saisies) et même chaque connexion génère de la donnée exploitable, revendable[^4] (traces numériques) ;
  • encadrement contractuel : encadrement de la participation ;
  • métriques de performance : mesure et récompense des performances

🔗 la donnée

Les internautes sont des « ‹ travailleurs qui s’ignorent ›, convaincus d’être plutôt des consommateurs, voire des bénéficiaires de services gratuits en ligne »[^1] (p.16) et automatiques.

Entraînement des algorithmes

Bien souvent, c’est un humain qui se cache derrière un algorithme d’« intelligence artificielle ». Des humains entraînent directement les résultats de Google, de Siri, modérant les posts Facebook, saisissent que tel photo contient bien un visage, que telle image contient tel texte. Ce cadre professionnel précaire, déjà peu visible, cache une usine mondiale :

Le crowdsourcing est la production participative (des internautes) par sous-traitance (des métiers que l’on cite au-dessus). Les usagers de certaines plateformes le font également, à l’insu de leur plein gré.

  • lorsque l’on rempli un captcha sensé empêcher les machines d’accéder à la fonctionnalités, on entraîne parallèlement les algorithmes de reconnaissance de caractères de Google ;
  • lorsque on identifie un ami sur une photo Facebook, on entraîne un logiciel de reconnaissance facial en indiquant que tel visage correspond à telle page et aux métadonnées qui y sont liées ;
  • en utilisant les filtres Snapchat ou Instagram appliqués à un visage scanné ;
  • lorsque l’on signale un contenu qui nous dérange.

On exploite la capacité des internautes à émettre des contributions de « faible intensité et à faible expertise ». Dominique Cardon paraphrase Yochai Benkler pour expliciter ce que ce dernier appelle le « miracle de l’agrégation » :

« Son argument était entièrement bâti sur l’idée que, situés au-dessus des contributions individuelles, sérialisées et locales des internautes, des mécanismes humains ou automatiques permettaient de produire autre chose, une connaissance publique, sans lien de continuité avec les contributions unitaires, mais qui résultait de l’effet coordonné des contributions unitaires. Ce mécanisme d’agrégation/transsubstantiation fait de l’intelligence collective un bien qui est plus que la somme des parties : les foules peuvent prendre des décisions ‹ sages › à partir d’opinions idiotes »[^1] (p.69)

Les algorithmes d’« intelligence artificielle » sont ou ont été sur-entraînées par des êtres humains. Non seulement ces services ont l’air automatiques, mais en plus les gens qui les entraînent ne se reconnaissent pas ou ne sont reconnus comme des travailleurs (des entraîneurs).

Travail cognitif

D’où l’expression « cognitariat »[^1] (p.34) (le nouveau prolétariat), soit le domaine des emplois non qualifiés, précaires, peu rémunéré et centré sur le cognitif : dialogue, coopération, échange. Pour la version web, on parle de « cybertariat » :

Service Action Biens
Uber Conduire quelqu’un voiture
Deliveroo, Uber Eats, Just Eat ivrer quelqu’un vélo
Airbnb Héberger quelqu’un appartement
TaskRabbit Rendre un service au domicile de quelqu’un
BeMyEye Prendre la photo d’un produit dans un magasin
Facebook, Google Interpréter un contenu ordinateur

On dresse le tableau suivant dans le cas de Deliverroo (et ses concurents). La même application vise plusieurs cibles, pour capturer certaines données et les revendre à des acheteurs. Non seulement le consommateur paie le service, mais il entraîne également d’autres conséquences économiques. Ainsi, les livreurs entraînent à leur insu des véhicules autonomes.

cible données capturées acheteur
consommateur Enregistrer ce que les gens mangents industrie agroalimentaire
restaurateur Évaluer la perfomance (en combien de temps ? Pour quelle note ?) catalogues touristiques
livreur Par quelles voies et comment (vitesse, gestion obstacles) ? fabriquants de véhicules autonomes

Sous couvert de sharing economy (service d’un particulier à un autre, mis en relation par les plateformes citées), les micro-travailleurs ne sont pas protégés, sont sans statut et mettent en jeu leurs propres biens :

« les entreprises propriétaires des applications mobiles ont dans le passé voulu se dégager de leurs obligations, en insistant sur le fait que leur activité se borne à l’intermédiation algorithmique. Une fois effectuée la mise en relation, leur responsabilité s’arrêterait »[^1] (p.24)

Ce premier travail en cache souvent un autre, plus discret, plus pervers. Quand un chauffeur Uber ou Deliveroo se déplace, il utilise l’application de la plateforme qui profite du voyage pour enregistrer des données sur le déplacement, le croisement avec d’autres chauffeurs. Ces données sont ensuite utilisées pour développer les applications dédiées au véhicules autonome : à terme, il remplaceront les chauffeurs qui ont entraînés leur propre succession, automatisée. D’un métier précaire ils iront… vers pas de métier.

« Le cœur de métier de ces nouvelles entreprises est l’exploitation algorithmique des données de mobilité et de consommation de leurs utilisateurs »[^1] (p.24)

Solution

Il ne serait pas éthique d’accepter une rémunération pour nos activités en ligne « face à l’impossibilité de protéger nos données personnelles » (p.37). Ce serait créer un nouveau « marché répugnant » des données personnelles (à classer non loin du commerce d’organes). Ce serait la « privatisation la privacy »[^1] (p.38).

« Quoique personnelles, ces données, ces productions digitales, ne sont pas du ressort de la propriété privée, mais le produit d’un commun, d’une collectivité. Par conséquent, la rémunération devrait chercher à redonner aux commons ce qui a été extrait des commons. »[^1] (p.38)

Antonio Casili a plutôt l’idée « d’un revenu de base », de « mesures redistributives ».

« Ce n’est pas parce qu’une entreprise est installée dans un certain pays qu’il faut l’imposer, mais parce qu’il y a des millions de citoyens qui réalisent un ‹ travail invisible › et gratuit pour cette entreprise »[^1] (p.40)

[^1]: Antonio Casili, Dominique Cardon, Qu’est-ce que le digital labor ?, 2015 [^2]: voir 🔗 production de contenu web [^4]: voir 🔗 économie documentaire des réseaux sociaux

discret / continu

id : 20210405121526
dernière édition :
type : processus

Dans la théorie des ensembles, on distingue les ensembles discrets et ensembles continus. Il s’agit d’un tout dont les propriétés de liaison entre les parties varient.

Discret

Cet ensemble est une suite d’items discontinue. Ils sont élémentaires, séparés les uns des autres et constituent des étapes intermédiaires dans la suite.

Par exemple, l’alphabet est un ensemble discret : A → B, C → D.

C’est une méthode pour isoler des éléments d’un système complexe et ainsi rendre calculables (par une machine) ce domaine.

🔗 travailler la complexité

Continu

Les items remarqués de cet ensemble sont séparés par une infinité d’autres items. Par exemple, l’ensemble des nombres réels (nombres avec décimal) est un ensemble continu : 1,1 ; 1,12 ; 1,13 ; 1,131 ; 1,2 ; 1,21.

La liaison s’étend entre des points infiniment loin les uns des autres.

discrétisation, granularité

id : 20210425141727
dernière édition :
type : programmation
mots-clés : Samuel Goyet

🔗 discret / continu

Plus un modèle 🔗 est granuleux (composé de nombreux éléments), discrétisé, plus les combinaisons 🔗 (les possibles) sont nombreux, pour une variété d’usages (il est moins standard et plus personnalisable). On peut alors généraliser le modèle ou bien observer ses nombreux éléments particuliers.

« les API web, en proposant une discrétisation maximale des formes qu’elles permettent de produire, en maximisent également les manipulations possibles […] plus une forme est discrétisée, plus elle est manipulable et plus elle va pouvoir circuler »[^1] (p.321)

La discrétisation d’une forme « a des conséquences sur les modes de représentation de cette forme et sur la littératie nécessaire pour la produire ». Discrétiser un modèle rend sont approche plus complexe 🔗, son inscription plus longue.

[^1]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

dispositifs d’une documentation logicielle hypertextuelle

id : 20210903104936
dernière édition :
type : documentation

Il existe différents outils pour réaliser la documentation (manuels d’utilisation, tutoriels, FAQ, encyclopédies, cahier des charges et convention de développement) d’un logiciel 🔗. Si elle peut être entièrement intégrée dans un site web (être hypertextuelle), il est nécessaire de combiner plusieurs outils (et techniques) pour rendre suffisamment de variété.

Génération de sites statiques

La documentation (en tant que site web) est disposée sur des sites statiques 🔗 générés grâce à différents outils, interprètes de certains langages et correspondant parfois à l’usage de certains environnements de développement 🔗.

Les principaux langages permettant d’inscrire de la documentation sont

  • Markdown 🔗
  • reStructuredText : balisage sémantique, filtrage de contenus.
  • AsciiDoc : format conçu pour l’impression de documents, tant sur écran que papier.
  • XML : nombreuses normes (DTD) pour construire des documents avec une architecture plastique, efficace et rigoureuse.

Ils sont inscrits via un éditeur de texte dans un répertoire de l’arborescence du logiciel. Ainsi, ils sont intégrés dans la structure du logiciel 🔗. De là, ils sont compilés 🔗 en site statique 🔗 grâce à l’un des outils suivants pour enfin être mis en ligne.

outil langage environnement de développement
Sphinx reStructuredText Python
Asciidoctor AsciiDoc

On intègre par la suite d’autres dispositifs à ces sites statiques pour rendre la présentation de la documentation plus poussée.

Démonstration

La modélisation 🔗 des différents niveaux de la structure du logiciel nécessite d’intégrer des outils de visualisations. Des outils comme Mermaid permettent de générer des visuels tout en inscrivant du texte dans le fichier source. Lequel restitue le schéma sous forme de texte, forme plus laborieuse, mais pérenne.

L’index de l’API 🔗 ne se prête pas à une démonstration du code source 🔗, pourtant nécessaire. Il est simplement sensé recenser les entités quand les tutoriels doivent en revanche être très explicites.

document

id : 20200708172120
dernière édition :
type : documentation
mots-clés : Bruno Bachimont, Arthur Perret, Jean-Michel Salaün, médiation

La notion de document « dont nous avons hérité au tournant des années 2000 a été façonnée par plusieurs décennies de tradition théorique ». Elle est « avant tout fonctionnelle, elle nous permet d’appréhender la trace écrite comme une information enregistrée en vue de sa transmission »[^2]

« un document est une inscription pourvue des trois propriétés suivantes : [1] elle est délimitée dans le temps et dans l’espace, [2] elle est intentionnelle et [3] elle est publiée. La délimitation dans l’espace permet de déterminer quelles sont les parties constituant le document. La délimitation dans le temps permet de déterminer un ordre canonique de parcours pour la consultation ou la lecture : elle fixe où commence et où s’arrête la lecture du document. La délimitation dans le temps et l’espace fixe donc la mise en ordre spatiale (la question de repérer les éléments constitutifs est décidable) et la mise en ordre temporelle (la question d’ordonner les éléments constitutifs est décidable). L’intentionnalité documentaire peut être a priori ou a posteriori. La publication permet d’établir une version de référence. »[^1]

Le document est le sujet de problématiques en tant que :

  • « une forme physique perceptible dont la matérialité physique [ou sa numérisation] se prête à l’instrumentation technique »[^3] ;
  • un signe avec ses problématiques de « manipulation, lecture et interprétation du contenu » ;
  • un medium, « objet social, objet de négociation et de transaction culturelle et économique », il est vecteur d’échange

« C’est parce qu’il prend une place dans une système documentaire que l’entité devient un document »[^4]

🔗 processus documentaire

Structure

Un document est une organisation d’informations dans un espace (ou même dans le temps, pour un document audiovisuel) de présentation défini dans la mesure où la structure du document va aussi contrôler sa lecture (ordre, rythme) et définir ses modalités d’interaction (lecture, annotation). Ainsi un document est un environnement dont la structure est explicite (table des matières, niveaux de titre) quand le contrôle et l’interaction sont suggérés.

« Le livre sert non seulement à énoncer des théories, mais à les construire ; non seulement à traduire une pensée, mais à la former. »[^5]

Variété

« La définition la plus générale qu’on puisse donne du Livre et du Document est celle-ci : un support d’une certaine matière et dimension, éventuellement d’un certain pliage ou enroulement sur lequel sont portés des signes représentatifs de certaines données intellectuelles. […] Le plus petit document c’est une inscription. »[^5]

Chez Otlet, le document est avant tout un support pour des inscriptions.

Selon la théorie de Bruno Bachimont :

  • Certains document permettent à la fois de conserver de l’information et de la diffuser ; c’est le cas avec les livres ou les affiches.
  • Certains documents (ineffables) ne sont qu’un encodage de l’information dont la diffusion se fait par un intermédiaire ; c’est le cas avec les VHS, CD.
  • Parmi cette seconde variété, le document numérique a une place particulière car il peut changer de forme à volonté (via un programme qui permettra de modifier la vue du document) selon l’appareil de diffusion : sous forme de feuille papier via une imprimante ou de page web via un navigateur. D’un même encodage de l’information on peut aboutir à différentes formes canoniques du document.

Valeurs

Liste des valeurs du document :

  • pédagogique : le document permet d’apprendre par son contenu. D’après l’étymologie : documentum, le modèle, l’exemple est dérivé sur latin docere, montrer, instruire)
  • juridique : question du droit, le document comme preuve, le document atteste, le document ne doit donc pas être falsifié.
  • historique : le document se garde, se mémorise et s’il passe l’épreuve du temps, il peut devenir un monument selon la maxime de Michel Foucault.

[^1]: Bruno Bachimont, Ingénierie des connaissances et des contenus, 2007 [^2]: Arthur Perret, Matière à pensées : outils d’édition et médiation de la créativité, 2018 [^3]: Stéphane Crozat et Bruno Bachimont, Réinterroger les structures documentaires : de la numérisation à l’informatisation, 2004 [^4]: Jean-Michel Salaün, Vu, lu, su. Les architectes de l’information face au monopole du web, 2012 [^5]: Paul Otlet, Traité de documentation, 1934

document numérique

id : 20210619161127
dernière édition :
type : documentation
mots-clés : Bruno Bachimont, Jean-Michel Salaün

🔗 document

Le document numérique est un document « orthothétique »[^1] (néologisme formé de orthotès, l’exactitude et thésis, la position) dans le sens où il reproduit (et objective) la structure sur un support immatériel. La document numérique est dans la continuité du document matériel. Toutefois, il n’est pas une simple copie ; représenter une feuille de papier sur écran ne fait pas de cette feuille un document numérique (c’est une feuille de papier numérisée). Elle ne permet alors pas de réagir au contexte informatique, notamment basé sur la copie, la validation d’informations.

Cependant, « le numérique marque une rupture dans la manière de concevoir et d’élaborer le contenu »[^1] : objectiver la structure du document (création de modèles, de fonctions et d’autres matériaux instanciables) nécessite d’abstraire le contenu, « donnant une contrepartie matérielle et manipulable »[^1] au document numérique, pouvant profiter des qualités de l'écriture numérique 🔗.

C’est ainsi qu’il devient possible de créer des protodocuments[^2] dans le processus documentaire 🔗, soit des copies d’une œuvre originale, prête à être adaptées et transformées pour de nouveaux envrionnements de consultation. Cette souplesse pose la question d’une philologie de l’écriture numérique, l’« art d’établir des versions de référence[^3] ».

Valeur de processus

Ainsi le document numérique est instable, falsifiable, souvent stocké dans un labyrinthe informationnel. On lui trouve d’autres qualités liés à sa décentralisation :

  • sa valeur juridique ne dépend plus du document comme support, mais comme processus ayant permis sa création ;
  • la valeur de son contenu ne dépend plus seulement de ses auteurs attribués, mais de sa processualité éditoriale 🔗.

[^1]: Stéphane Crozat et Bruno Bachimont, Réinterroger les structures documentaires : de la numérisation à l’informatisation, 2004 [^2]: Jean-Michel Salaün, Vu, lu, su. Les architectes de l’information face au monopole du web, 2012 [^3]: Bruno Bachimont, Rhétorique de l’intelligibilité, vers des humanités du numérique, 2020

document procédural

id : 20210921134404
dernière édition :
type : documentation

Un document procédural indique quelles sont les actions à réaliser (procédure, suite de consignes) « pour atteindre le résultat attendu à partir d’un état de départ connu »[^1] (p.53).

Objet

Le document procédural a une fonction pragmatique, il « indique le ‹ faire › (par exemple en indiquant : ‹ Réaliser telle action ›) et non le ‹ comment faire › (par exemple en indiquant : ‹ Réaliser telle action en utilisant tel outil de telle façon ›) »[^1] (p.53) [^2].

« il s’agit plus de ‹ lire pour faire ›, que ‹ lire pour apprendre › [… le texte procédural est] ‹ au service de l’action › [… pour] guider un utilisateur dans la réalisation d’une tâche, soit parce que celle-ci lui est inhabituelle, soit parce qu’elle est considérée comme trop complexe par rapport à ses compétences »[^3]

Utilisation

La « lecture-compréhension » du document technique « ne devrait constituer qu’une activité secondaire […] , l’activité principale de l’utilisateur étant d’apprendre à utiliser, manipuler, assembler ou encore résoudre un problème (c’est d’ailleurs pour cette raison que le destinataire de ce type de document n’est généralement pas qualifié de ‹ lecteur ›, mais plutôt d’‹ utilisateur › »[^3] (p.72)

Ainsi, le document technique doit se mettre en retrait, « faciliter l’activité de compréhension, afin de permettre à l’utilisateur de mobiliser ses ressources attentionnelles et cognitives au profit de la réalisation de la tâche »[^3] (p.72). On surcharge cette activité avec un document incomplet ou imprécis.

Qualité

Ces documents sont souvent d’une qualité médiocre suivant une utilisation peu efficace[^3] (p.72) On juge ces documents efficaces dès lors qu’ils permettent une « réalisation efficace et sans erreur »[^3] (p.71). C’est possible en limitant au maximum l’interprétation[^2] que peut en faire l’utilisateur. Un erreur d’interprétation peut en effet avoir de lourde conséquence (ayant provoqué une mauvaise, voire dangereuse utilisation).

La qualité des documents procéduraux vient principalement la qualité de l’écriture technique 🔗.

La perte de qualité est souvent due à un manque d’empathie de la part du rédacteur technique, causée par le distance qui les sépare. Ce sont souvent des techniciens plus que des rédacteurs. Ils postulent à tord que l’utilisateur dispose de certaines informations clés, sachant que leur niveau de littératie 🔗 est très variable[^3] (p.74).

Rédaction

Ils sont souvent rédigés collaborativement, « la production d’un document procédural nécessite de le découper en plusieurs sous-parties réparties entre plusieurs rédacteurs techniques »[^1] (p.53).

Les rédacteurs doivent faire des choix[^3] (p.74) [^1] (p.55) dans leur rédaction dans trois domaines. Pour ce faire ils doivent utiliser des modèles 🔗 permettant de disposer une information régulière et cadrée (pour les d’exhaustivité, de précision).

  • « choix des informations à transmettre (ordre d’importance des informations, niveau de finesse de la description, formulation, terminologie, etc.) »
  • « choix du format à utiliser pour transmettre ces informations (texte, image, tableau, arborescence, etc.) »
  • « type d’organisation à adopter dans la mise en page de façon à aider l’utilisateur à rechercher les informations pertinentes »

Il faut durant la rédaction doser le niveau d’abstraction 🔗, « un niveau d’abstraction des instructions trop élevé, conduisant à un guidage insuffisant, ou au contraire, un niveau de granularité trop fin, conduisant à une multiplication des références au texte, et donc à une ‹ surcharge › d’information »[^3] (p.75)

Révision

La révision est un « processus de lecture, compréhension, détection, diagnostic »[^3] (p.75) appliqué à tout ou partie d’un texte, produit ou en production.

  • niveau global (macro-structurel) : précision, exactitude, pertinence, agencement des informations
  • niveau local (micro-structurel) : syntaxe, orthographe, terminologie, typographie

Le plus efficace pour la révision est de posséder des outils automatiques pour « déplacer, ajouter, supprimer ou modifier l’information de façon plus ou moins systématique »[^3] (p.76)

[^1]: Corinne Grosse, Flore Barcellini, Patrick Saint-dizier, Vers la conception d’un outil d’assistance à la rédaction technique, 2012 [^2]: Michel Fayol, Les documents techniques: Bilan et perspectives, 2002 [^3]: Franck Ganier, La révision de textes procéduraux, 2006

documentarisation

id : 20210408172535
dernière édition :
type : documentation
mots-clés : Manuel Zacklad, médiation, technique

La documentarisation est un traitement documentaire permettant

  • de singulariser un document pour pouvoir le retrouver dans une base (documentarisation externe)
  • « mettre en cohérence et à articuler les différents fragments qui constituent le ‹ texte › »[^1] (documentarisation interne)

Un document avec une forte granularité 🔗 est un document pourvu de nombreux fragments.

« La documentarisation est une activité d’annotation au sens élargi que nous donnons à ce terme, susceptible de remplir trois fonctions complémentaires, attentionnelle, associative, contributive. Elle peut recourir à divers procédés allant de la sélection de propriétés typographiques visant à mettre en relief certaines parties du texte, annotations attentionnelles, à l’utilisation de langages d’organisation des connaissances systématisées contribuant à la classification, à l’indexation, à la contextualisation temporelle ou sociale du document, annotations associatives et contributives »[^1]

La documentarisation permet de retrouver un document dans une base, mais peut aussi permettre de lui donner sa fonction (ex : dater un document cessé être une preuve, sans quoi il serait invalide).

« La documentarisation correspond à des opérations d’inscription particulières qui visent à permettre la réutilisation du support dans le cadre de transactions ultérieures de la personne avec elle-même ou avec d’autres personnes mémorisation et coordination »[^1]

[^1]: Manuel Zacklad, Genres de dispositifs de médiation numérique et régimes de documentalité, 2015

documentation du processus du logiciel

id : 20210928105516
dernière édition :
type : documentation

La documentation du processus du logiciel permet à ses concepteurs d’assurer son développement ; dans le temps et l’espace ; en terme de projet (jalonné 🔗, dans un environnement de développement 🔗 défini) et d’architecture 🔗 (modularisé 🔗, synchonisé 🔗). Elle s’adresse à des utilisateurs fluides 🔗, capables de saisir la nature hypertextuelle de l’envrionnement du logiciel 🔗.

« Une gestion efficace [du développement du logiciel] exige que le processus géré soit visible. Comme les logiciels sont intangibles et que le processus logiciel implique des tâches cognitives apparemment similaires plutôt que des tâches physiques manifestement différentes, la seule façon d’obtenir cette visibilité est d’utiliser la documentation du processus »[^1] (p.3)

Ian Sommerville[^1] (p.3) établit que cette documentation doit répondre aux besoins suivants :

  1. Plans, estimations et calendriers : Planification des étapes du cycle de développement logiciel 🔗 (spécification, conception, implémentation, test…) ;
  2. Rapports : Utilisation des ressources dédiées au développement ;
  3. Normes : Manière dont le processus doit être mis en œuvre, à partir de normes locales ou externes comme disposées par la convention de développement 🔗 ;
  4. Documents de travail : Idées et les réflexions des concepteurs pour élaborer le développement ;
  5. Mémos et communications : Détail des communications informelles ou non au sein du projet (échanges interpersonnels, réunions…).

La documentation du processus du logiciel peut se faire à plusieurs échelles selon Scott Robert Tilley[^4]. Il différencie documenting-in-the-small et documenting-in-the-large. Il estime qu’il faut adapter la documentation selon le taille du projet ; « il y a des différences significatives entre des systèmes logiciels de 1 000, de 100 000 ou de 1 000 000 de lignes »[^4] (p.1) et la plus importante est « l’usage de la documentation comme aide à la compréhension du programme ». Arrivé à un certain stage, il est nécessaire de posséder un support pour aider à la lecture du programme[^4] (p.2).

Expliciter le processus

La documentation du processus de développement du logiciel doit inclure un historique des décisions prises pour la programmation du logiciel[^3] (p.553). Il permettra de comprendre, de valider, retravailler ou réutiliser les hypothèses de programmation déjà exploitées, de ne pas travailler une hypothèse déjà traitée (qu’elle ait été rejetée ou non).

Cet historique permet de faire de la rétro-ingénierie[^4] (p.1) 🔗 sur le système. Cela conciste à

Cycle de rédaction

La plupart des processus documentés deviennent (rapidement) obsolètes. Ainsi, il faut prévoir de réactualiser régulièrement cette documentation lors des revues de code 🔗. Les communications au sein de l’équipe peuvent être archivées, mais si elles sont pertinentes, il faudra les réintégrer dans une partie pérenne de la documentation, comme au sein des documents de travail. Au contraire, les normes doivent rester stables.

« L’accès à ces informations permet d’éviter d’apporter des changements qui vont à l’encontre de ces décisions initiales »[^1] (p.4)

En terme de projet

Le développement du logiciel est un processus social complexe que la documentation se doit de traiter. Elle doit faciliter les interactions entre les personnes affairantes, faire médiation de l’une à l’autre en fournissant un référentiel commun (de fonctionnalités, de vocabulaire, de techniques) et des biographies.

« La base de connaissances d’un projet est immense, et une grande partie de cette connaissance consiste à connaître les rituels de négociation de l’équipe, quelle personne connaît quelle information, qui a fortement contribué au dernière dernière version du projet, quels éléments de discussion ont permis de prendre certaines décisions de conception, et ainsi de suite »[^2] (p.130)

[^1]: Ian Sommerville, Software Documentation, 2001 [^2]: Alistair Cockburn, Agile Software Development, 2002 [^3]: Ruven Brooks, Towards a theory of the comprehension of computer programs, 1983 [^4]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

documentation du produit logiciel

id : 20210928112324
dernière édition :
type : documentation

La documentation du produit logiciel répond à deux niveaux d’utilisation du logiciel 🔗. Deux parties s’entremêlent[^1] (p.4) (au moins grâce à des liens hypertextes), destinées

  • à l’utilisateur : comment utiliser et dépanner le logiciel (grâce à un mode d’emploi 🔗) ?
  • au réutilisateur : comment fonctionne le logiciel et comment manipuler ses éléments ?

Les développeurs doivent également saisir ces notions ; l’une après l’autre, elles décrivent ce qui doit fonctionner, comme une liste de tests finaux. Toutefois, leur intention ne peut aboutir grâce à ce document.

C’est une documentation relativement pérenne, au moins attachée à chaque version majeure du logiciel. Laquelle vient radicalement changer tout ou partie de son fonctionnement et nécessite donc une actualisation de cette documentation.

[^1]: Ian Sommerville, Software Documentation, 2001

documentation intégrée à l’interface du logiciel

id : 20210619155409
dernière édition :
type : documentation

La documentation d’un logiciel peut être directement intégrée à son interface et ainsi ajouter aux informations qu’elle délivre le contexte d’utilisation[^2]. On produit alors un véritable dialogue entre l’utilisateur et le narrateur du mode d’emploi 🔗 ; il y a à la fois le geste et une explication éclairée de ce qui a été effectué et de ses conséquences. Ainsi, le manuel d’utilisation n’est plus une pièce rapportée, mais intègre une expérience cohérente au service de la compréhension de l’utilisateur.

« L’aide en ligne présente l’avantage, par rapport à la documentation [manuel d’utilisation], de pouvoir être sensible au contexte. Par exemple […] l’utilisateur peut pointer les éléments d’une boîte de dialogue pour qu’ils soient expliqués par une ‹ bulle d’aide › »[^1] (p.150)

Architecture

Le travail d’architecture du code source et de l’interface du logiciel devient autant le soucis des développeurs que des designers (concepteurs de l’intéraction). Comme pour les messages d’erreur 🔗, l’intégration de ces boîtes de dialogue est un double défis d’architecture. Il y a à la fois un travail de design pour qu’elles soient bien visibles et à la fois un travail de programmation pour le diagnostic efficace et le renvoie d’un message adapté. Plus le diagnostic est fin, plus le message d’erreur pourra être pertinent.

Intégration

La forme de ces messages varie en fonction du type d’interface, selon qu’il s’agisse d’une GUI (graphical user interface, interface graphique) ou d’un terminal :

interface graphique terminal
intéraction boutons (souris et clavier) formulaire (clavier)
outil sémiotique icônes, couleurs caractères, couleurs
référence liens hypertexte, volet de détails identifiants, code erreur
activation clic, survol exécution, commande

Les boutons (« J’ai compris », « En savoir plus ») et champs de formulaire (« Tapez ‹ oui › pour confirmer, ou appuyez sur un autre touche pour annuler ») doivent instaurer un dialogue entre le logiciel et l’utilisateur. Il faut bien faire comprendre à l’utilisateur le choix qu’il va opérer, mais aussi les conséquences de ce choix (« Vous allez être redirigé », « Cette action est irréversible, les données seront perdues »).

« Un bon dialogue nécessite peu d'entraînement et devient rapidement automatique […] afin que l'utilisateur puisse se concentrer sur le sujet et sur la tâche à accomplir, plutôt que sur le fonctionnement du système »[^2] (p.32)

[^1]: Jakob Nielsen, Usability Engineering, 1993 [^2]: Wiliam Horton, Designing & writting online documentation, 1990

documentation logicielle

id : 20210118161126
dernière édition :
type : documentation

La documentation d’un logiciel est une série de documents présentant ses usages et solutions de développement. Elle fait une médiation 🔗 entre une variété d’utilisateurs du logiciel 🔗 et les différents niveaux d’utilisation du logiciel 🔗.

Au coeur du projet logiciel

La documentation est le fil conducteur du cycle de développement du logiciel 🔗. Elle sert autant à médier les informations entre l’équipe de développement, qu’à le budgetiser et planifier[^5] (p.2).

La documentation est dans une premier temps l’outil des développeurs, relative au processus 🔗. Elle est principalement rédigée par les architectes du logiciel 🔗, selon le projet qui leur a été commandé. Elle sera ensuite complétée par les développeurs 🔗 au fil de leur travail.

« La documentation est une abstraction des connaissances sur un système logiciel »[^5] (p.10)

« l’écriture de code et sa documentation sont en fait le même type d’effort à un certain niveau d’abstraction. L’ingénierie documentaire n’est pas un moindre challenge intellectuel que l’ingénierie logicielle, et offre certainement un plus grand potentiel opérationnel »[^8] (p.48)

Durant la production du logiciel, des rédacteurs techniques (les mêmes développeurs ou d’autres) ajouterons à la documentation les informations relatives au produit 🔗. Elle pourra éventuellement être complétée par des utilisateurs selon les modalités choisies par les administrateurs.

« La satisfaction de ces exigences nécessite différents types de documents, depuis les documents de travail informels jusqu’aux manuels d’utilisation produits par des professionnels »[^4] (p.2)

Sans documentation, un logiciel ne peut être utilisé ou maintenu 🔗 ; il n’a pas d’histoire et donc aucun avenir ; il n’existe que dans l’instant de développement ou d’utilisation. La documentation logicielle est un pilier, un point de rencontre entre les partis d’un logiciel (quelque soit leur utilisation 🔗) pour se concerter autour d’une information. C’est ainsi qu’elle permet de résoudre les erreurs de synchronisation entre développeurs et avec les utilisateurs. Quand les idées ne suivent plus, leur inscription permet de retrouver le chemin du fonctionnement. Toutefois, il serait illusoire de se dire que « si quelqu’un quitte le projet, une personne de remplacement pourra se joindre au projet, lire la documentation et reprendre là où l’autre personne s’est arrêtée »[^7] (p.31). La documentation n’est pas un dispositif suffisemment effiace.

Miroir de l’architecture

L’architecture du logiciel 🔗 est déterminante dans le processus de documentation. La documentation suit les choix d’ingénierie logicielle. Qu’importe le niveau d’utilisation 🔗, elle change la manière dont les problématiques sont abordées, résolues et évaluées par l’équipe de développent, pour les usagers. Aussi, s’il est important de modulariser son code 🔗, il est aussi important de modulariser sa documentation, de structurer notre approche des différents problèmes.

Ne pas mettre à jour la documentation au fur et à mesure du développement mène à une décorrélation entre les explications (aux utilisateurs, réutilisateurs et développeurs) et les évolutions du programme. C’est quelque chose qui apparaît rapidement et qu’il est couteux de contrer, bien que cela impacte lourdement l’utilisabilité 🔗 et la maintenance 🔗 du logiciel « les mainteneurs de code s’attendent à cette discordance, et utilisent donc la documentation défectueuse comme un moyen de se ‹ rapprocher › de la zone de la zone qui doit être modifiée. Dès qu’ils sont proches, leurs yeux et leur intelligence se chargent du reste »[^7] (p.63). Dans l’idéal, le code source change (ajout, modification, retrait) et la documentation évolue en miroir, grâce une relecture régulière pour garder de la cohérence entre les informations ; sa documentation devrait être un projet parallèle au logiciel

La meilleure façon de lier l’architecture du logiciel 🔗 à la documentation est de l’intégrer à son arborescence. Elle est intégrée directement dans le code source du logiciel d’où on documente le code source 🔗 et où sont rédigés les différents fragments de cette documentation.

Format

La documentation d’un logiciel peut prendre la forme d’un site web 🔗 (consulable en ligne) ou d’un document paginé (imprimé ou non). Le format web est plus fidèle à l’environnement hypertextuel des logiciels 🔗.

Dans tous les cas, la documentation est faite d’une série de documents (riches en dispositifs, variés et pertinents) répondant aux différents niveaux d’utilisation du logiciel 🔗. Ils sont eux-mêmes décomposés en fragments documentarisés 🔗.

nom usage niveau d'utilisation 🔗
documentation intégrée au logiciel 🔗 fournir une aide adaptée au contexte d'utilisation, messages d'erreur utilisateur
manuel d'utilisation utilisation détaillée, exhaustive et dépannage utilisateur
convention de développement 🔗 synchronisation des moyens (jargon, paradigmes, outils) entre les développeurs développeur
index de l’API 🔗 liste et description des artefacts du logiciel réutilisateur
rapport des spécifications 🔗 et de leurs tests associés développeur
modèles intégrés à l'architecture développeur

« L’interdépendance entre les documents est grande : il existe des relations entre les différentes parties de la documentation et entre la documentation et le code source. »[^2] (p.8)

Variété documentaire

Pour embrasser la variété des problèmes rencontrés par les utilisateurs et les développeurs dans leur rapport au logiciel, mais aussi s’adapter à leurs connaissances et leurs capacités heuristiques, on dote ces différents documents de 4 dispositifs, comme suggéré par Jakob Nielsen[^3] (p.153) (et Matthias Dugué[^1]) :

document sujet usage
manuel Concepts, notions permettant de représenter l’usage. utilisation
tutoriel Présentation d’un problème de départ suivie d’une série d’instructions pour le résoudre. échec, panne
FAQ Réponses rapides à des questions évidentes, récurrentes évaluation
encyclopédie Explications sur le projet logiciel, son fonctionnement, son environnement passerelle

Les passerelles permettent aux utilisateurs expérimentés en informatique de devenir réutilisateur, de passer de l’autre côté via une médiation. L’encyclopédie et l’index de l’API 🔗 peuvent facilement amener un utilisateur savant à s’approprier des notions de l’architecture logicielle 🔗.

« il est important que chaque type de manuel soit aussi autonome que possible. Les utilisateurs ne doivent pas avoir à combiner des informations provenant de plusieurs volumes afin de résoudre des problèmes typiques »[^3] (p.153)

« ingénierie documentaire est devenue un sous-domaine populaire dans la communauté de l’ingénierie logicielle »[^5] (p.III)

Naviguer entre les informations

Pour constituer la documentation, il faut sélectionner les informations les plus pertinentes et leur contexte de présentation, faire de la curation. Ces contenus doivent être reliés par des liens hypertexte 🔗, classés grâce à la même taxonomie qui permet de nommer les variables 🔗. Cela permet tant à l’utilisateur, qu’au réutilisateur, qu’au développeur d’explorer le réseau de connaissances, de développer une stratégie de navigation 🔗, plutôt que consulter linéairement une liste d’éventuelles solutions.

« le problème de l’utilisateur est souvent lié au fait qu’il veut faire autre chose que ce qui est offert par l’état actuel du système, de sorte qu’il devrait également être possible pour l’utilisateur de poser des questions axées sur la tâche »[^3] (p.150)

En tant que document numérique 🔗, la documentation peut être pourvue de nombreux outils de recherche, de transclusion 🔗 qui permettent à l’utilisateur de retrouver une information.

On ne peut se contenter de texte lorsque l’on parle d’architecture 🔗. Pour le comprendre, il est nécessaire de comprendre le rapport entre différents composants, leurs relations hypertextuelle 🔗.

« Une nécessité dans ce cadre est de pouvoir accéder au code source et à la documentation via une description sémantique de leur contenu. L’environnement doit être capable de gérer en plus du contenu textuel, voire graphique, des composants logiciels, leur contenu sémantique sous forme de termes d’indexation de structure plus ou moins complexe (mots-clés, graphes conceptuels, etc.) »[^2] (p.5)

Qualités

Les qualités d’une documentation logicielle[^6] (p.1) sont

  • exhaustive (complète)
  • synchronisée (à jour)
  • pertinente (précise, adaptée à ses usagers 🔗)
  • utile : On doit remettre en question toutes implémentation, aussi bien dans le code que dans la documentation[^5] (p.13).

Frein

La documentation écrite en langue naturelle contient nécessairement des « informations incohérentes et incomplètes »[^5] (p.8). La solution serait de concevoir une documentation mathématique, « décrivant les logiciels à l’aide de relations mathématiques tabulaires »[^5] (p.8). Ces exigences sont autant de freins à la documentation ; ils appellent une documentation laborieuse tant pour son écriture que sa lecture[^7] (p.39).

« C’est un fait bien connu que la documentation des logiciels est, en pratique, pauvre et incomplète. […] la plupart des gens pensent qu’une certaine forme de documentation est nécessaire mais il y a généralement peu d’accords sur ce qui est nécessaire. Plus surprenant encore, dans la pratique quotidienne les gens utilisent en fait une documentation incomplète et obsolète et la trouvent utile »[^6] (p.1)

« Nous ne savons pas vraiment dans quelle mesure nous devrions documenter afin d’équilibrer les compromis entre, d’une part, l’allocation de ressources trop importantes à la documentation, ce qui entrave le développement actuel, et, d’autre part, l’allocation de ressources insuffisantes, ce qui entrave le développement futur. Pour compliquer les choses, l’augmentation des ressources de documentation n’améliore pas nécessairement le développement futur du logiciel (le but ultime de la documentation) parce que nous ne comprenons pas vraiment ce qui définit la qualité de la documentation »[^5] (p.III)

« ‹ Les projets de documentation sont toujours en retard et dépassent le budget, et la qualité du résultat final est décevante › ‹ La documentation est un problème que tout le monde connaît et souhaite voir disparaître › ‹ Personne n’a jamais vraiment envie de rédiger de la documentation technique. C’est une réflexion ennuyeuse après que tout le travail soit terminé › »[^8] (p.48)

[^1]: Matthias Dugué, Revoir la documentation, de zéro, 2019 [^2]: Sahar Jarwah, Un modèle générique pour la gestion des informations complexes et dynamiques, 1992 [^3]: Jakob Nielsen, Usability Engineering, 1993 [^4]: Wiliam Horton, Designing & writting online documentation, 1990 [^5]: Ian Sommerville, Software Documentation, 2001 [^6]: Lionel Briand, Software documentation: how much is enough?, 2003 [^7]: Alistair Cockburn, Agile Software Development, 2002 [^8]: Janet H. Walker, Supporting document development with Concordia, 1988

documenter le code

id : 20210520191108
dernière édition :
type : documentation

Le code source d’un programme constitue sa documentation ultime et primordiale. Le code source est une documentation 🔗 par lui-même. Le code auto-documenté est particulièrement explicite. C’est une tâche permanente des développeurs selon le paradigme de la programmation lettrée 🔗.

Le code est la dernière interface de lecture/écriture (et non de contrôle) du logiciel. Bien que l’on puisse utiliser les outils de la raison graphique (liste, tableau, formule) le contexte de lecture est presque toujours un éditeur de texte avec les difficultés de lecture que cela implique (lassitude devant des caractères uniformes, longueur des lignes…). Ce genre de documentation ne rend pas compte de la nature hypertextuelle de la structure du programme 🔗, les unités sont généralement peu détaillés et le tout n’est que texte, sans représentation graphique. Il faut donc la compléter.

Cette forme de documentation a l’avantage d’accompagner directement le code en tant que matériel technico-sémantique (fonctionnel par son sens, dans un certain contexte). Le code est quant à lui le support de cette élaboration dans la logique de la programmation lettrée 🔗. Il ne faut toutefois pas confondre l’explication des instructions et l’explication du fonctionnement du programme, de son contrôle sur la machine, sous peine d’ensourcellement 🔗.

Lexique

La documentation du code est un processus continu. Les rédacteurs n’annotent pas en permanence leur code. Ce n’est pas toujours la solution la plus efficace pour explicier son intention. Cela nécessite de cesser la rédaction logique et fonctionnelle pour se consacrer à la prose. Ce travail parallèle prend du temps, sans ajouter de fonctionnalités au logiciel. On veut pouvoir garder un code aussi explicite que fonctionnel en faisant des choix lors de son écriture techno-sémiotique. Le nom d’une variable 🔗 est déterminant dans la documentation du code, c’est pourquoi on soigne le nommage des variables 🔗.

Annotation

Il est possible pour le développeur d’inscrire de la prose aux différentes échelles de la structure du logiciel 🔗. Il peut ainsi expliciter le développement du logiciel, apporter des précisions sur les processus et modèles 🔗 :

  1. arborescence des répertoires → fichiers « readme »
  2. fichier → blocs de commentaires d’entête
  3. structures de contrôle → blocs de commentaires
  4. variables et constantes → blocs et commentaires en ligne

Ils sont en général rédigés en anglais avec la syntaxe Markdown 🔗.

Il faut bien faire attention à mettre à jour ces annotations lorsque l’on modifie le code source comme en cas de refactoring 🔗. On a rapidement changé le type d’une variable ou supprimé une fonction. Intégrer la documentation au code permet aussi de vérifier que chaque nouvelle implémentation 🔗 a correctement été documentée et est donc prête à être publiée[^1].

Fichiers « readme »

Le fichier « readme » est placé à la racine de l’arborescence et dans les différents répertoires qui nécessitent une explicitation. À la racine il donne les informations essentielles sur le téléchargement, l’installation, la contribution… Dans les autres répertoires il permet de donner aux lecteurs des informations utiles sur les modèles 🔗 instanciés en son sein et de présenter portions de code, des commandes utiles dans ce répertoire.

Entêtes

À partir de l’échelle 2, des logiciels comme JSDoc ou phpDocumentor permettent de générer un index de l’API 🔗 grâce aux blocs de commentaire de code 🔗. Il y inscrit différents drapeaux permettant de marquer différentes informations. Ces drapeaux appartiennent à un vocabulaire contrôlé (JSDoc dans les exemples ci-après), même si la relation n’est pas explicite (rien ne permet donc d’affirmer qu’il s’agit d’une ontologie 🔗).

Les entêtes prennent beaucoup de place, transmettent généralement peu d’informations et elle est en partie redondante. On répète le nom des paramètres, la portée et le type des variables et d’autres informations évidentes pour un développeur qui lirait le code source. On trouve ces entêtes utiles pour générer l’index de l’API 🔗 et y décrire la fonction sans que le lecteur n’ait à lire le code source. Dans cette logique de publication en ligne, on retrouve le drapeau @link permettant de faire des liens hypertextes vers une autre entête.

On peut également trouver très utiles ces entête dans la logique de la programmation lettrée 🔗. Elles peuvent contenir toutes les remarques d’un développeur sur son propore code, lui permettant de présenter ses intentions, les alternatives qu’il a identifié. On documente les questions « pourquoi ? » et « pourquoi pas ? ». On évite ainsi qu’une autre personne fasse les mêmes tests que nous avec la même issue. Il pourra insrire une description plus brève de la fonction en utilisant le drapeau @summary, décrire les ajouts à apporter grâce à @todo. Les @since

Du fichier

Ci-dessous un exemple d’entête de fichier décrivant son contenu, son auteur/responsable de l’implémentation, la licence 🔗 qui le concerne et une tâche restant à effectuer.

/**
 * @file Library document management
 * @author Guillaume Brioudes <https://myllaume.fr/>
 * @copyright GNU General Public License
 * @todo Ajouter la supprission des livres
 */

De la structure de contrôle

Ci-dessous un exemple d’entête d’une fonction 🔗. Cet entête décrit la fonction, ses paramètres title, authors et nbPage, respectivement une chaîne de caractère, un tableau et un nombre entier. Enfin, cette fonction renvoie un booléen. On annote à l’échelle d’une structure de contrôle 🔗.

/**
 * Represents a book.
 * @param {string} title - The title of the book.
 * @param {array} authors - The author of the book.
 * @param {int} nbPage - Number of page.
 * @return {bool} True if no error
 */

function Book(title, authors, nbPage) {…}

De la variable

Ci-dessous un exemple de commentaire pour une constante. Cet entête indique que la variable a un valeur constante, qu’elle doit être un nombre (afin rester cohérente avec le reste du système) et que sa valeur par défaut est 143 (ce qui sera noté dans l’index de l’API 🔗 pour que la valeur puisse être retrouvée). On annote à l’échelle d’une variable 🔗.

/**
 * Number of books to generate.
 * @constant
 * @type {number}
 * @default
 */

const books = 143;

Il suffirait d’être plus explicite sur le nom de la variable pour éviter d’avoir à préciser le type. Le nom nbBooks suggèrerait à lui seul le type de la constante.

En ligne

Les commentaires de code 🔗 sur une ligne permettent d’apporter des précisions sur un détail d’une opération qui ne serait pas intuitive. Il est préférable de refactoriser 🔗 du code trop complexe plutôt que de compenser sa complexité. Toutefois, ça n’est pas toujours possible, faute de savoir-faire, faute de temps. Dans ce cas, une phrase peut faire gagner beaucoup de temps à la relecture.

Les messages d’erreur 🔗 sont une forme de commentaire du code. Ils permettent d’inscrire une phrase explicitant une exception dans le code ce qui guide le programmeur à la lecture ou l’attire à l’utilisation : la console des nombreux envrionnements d’execution 🔗 relaie en général le message avec le numéro de ligne.

Informer une arborescence

La portée de l’information de ces annotations est limitée à la fonction de l’arborescence 🔗 d’un répertoire. Chaque répertoire hérite des informations de son répertoire parent auxquelles il ajoute les sienne (via le README.md qu’il intègre) pour les infuser dans ses répertoires et fichiers enfants. Lesquels ne peuvent communiquer leurs attributs particuliers à leurs frères.

root/
├── README.md
└── functions/
    ├── README.md
    ├── index.js
    └── utils/
        ├── README.md
        └── count.js

Prennons comme exemple les fichiers ci-dessous, placés dans le même répertoire. Dans cet exemple, le fichier README.md donne des informations sur l’ensemble des fichiers contenus dans son répertoire et des classes qu’ils contiennent. Dans ces fichiers, les entêtes réutilisent ces informations et en précisent certaines variables que les commentaires en ligne précisent encore.

Ces informations se concrétisent dans l’implémentation. Le fichier README.md présente des classes abstraites 🔗 dont héritent (extends modelA) les fichiers enfants.

--- README.md (Markdown) ---

Présentation des modèles :

- model A = Classe avec description des états … voir le code exemple plus bas dans le fichier …
- model B = …

--- function.js (CommonJS) ---

/**
 * @file Class use model A
 */

/**
 * Get a dataset with a name.
 *
 * Additionnal states :
 * - **empty** : no data to output
 * - **noempty** : some data
 */
 
module.exports = class Data extends modelA {

    static statesList = modelA.statesList.concat([
        // Héritage depuis model A
        'empty' // Pas de données à exporter
        'noempty' // Il y a des données à exporter
    ]) 

    constructor (data) {
        this.state = '…' // Quelques précisions
    }
}

Dans ce système n’est pas possible de faire référence à des classes qui auraient pu être présentés dans d’autres fichiers README.md, depuis d’autres répertoires. Pourtant, CommonJS permet d’appeler des classes définies dans d’autres (répertoires) parties de l’arborescence du logiciel. En effet, il faudrait privilégier un documentation en rhizome 🔗 plutôt qu’en arborescence si l’on se fie à la nature hypertextuelle du développement logiciel 🔗.

[^1]: Eric Holscher, Docs as Code

DOM, document objet model

id : 20200704160828
dernière édition :
type : architecture

Le DOM (Document Object Model) est une API 🔗 présentée sous la forme d’une arborescence d’objets. Ils prennent la forme de balises telles qu’on les écrits en HTML, avec leurs attributs. Toutefois le DOM comprend aussi les affectations CSS 🔗 et JavaScript 🔗, ce dernier permettant d’actualiser dynamiquement le DOM.

Indentation

Chaque balise est un potentiel nœud, une potentielle parente d’autres balises dans l’arborescence.

Le nœud est une articulation de la page et il est possible d’affecter des balises en masse en ciblant leur parent (fonction récursive).

<ul class="list">
    <li class="list__item">Lorem ipsum</li>
    <li class="list__item">Lorem ipsum</li>
</ul>
<button id="cible">Ajouter élément</button>

Objets

Le DOM est une structure abstraite permettant aux développeur·euse·s d’ancrer des attributs et fonctions sur les éléments qui composent une page web.

Chaque objet tel qu’il est délimité par les balises (entre chevrons) a ses propres attributs (comme l’attribut class visible ci-dessus) et méthodes qu’il est possible de leur affecter en CSS ou en JavaScript. Cette notion de classe renvoie directement aux principes de la programmation orientée objet 🔗.

Pour se faire il est nécessaire de sélectionner (comme ci-dessus avec le bouton, via son attribut id) l’objet avec de pouvoir le manipuler. Toujours dans une logique orientée objet, la convention BEM 🔗 permet d’appréhender de manière structurée le DOM.

La méthode typique affectée à un objet du DOM est l’ajout d’événement (addEventListener), comme ci-dessous :

var button = document.querySelector('#cible')
	.addEventListener('click', fonction);

Shadow DOM

Le Shadow DOM (aussi appelé Virtual DOM, DOM fantôme) est une structure cachée du DOM permettant d’intégrer dans les pages web des arborescence d’objets indépendantes. Les objets y sont soustraits aux règles globales du DOM comme les sélecteurs CSS ou JavaScript. Ainsi il est possible de modulariser 🔗 la page web, d’isoler des composants.

Cet environnement peut être manipulé en JavaScript. Il sert notamment aux navigateurs pour mettre en place les lecteurs vidéos à l’insertion de la balise <video>. Ils sont composés de nombreux éléments, mais intouchables nativement, par les affectations globales.

domaine des humanités numériques

id : 20200725085518
dernière édition :
type : undefined
mots-clés : Olivier Le Deuff, Éric Guichard

Les humanités numériques (aussi appelées humanités digitales) sont un champ de recherche scientifique transdisciplinaire. Il vient en aide et se nourrit d’autres disciplines par des pratiques croisées de chercheurs, souvent issus des sciences humaines et sociales (SHS) ou même des arts.

Il s’agit globalement d’extraire, traiter (analyser, encoder, modéliser… ) et partager de la connaissance. C’est aussi un champ de recherche sur la culture numérique.

Humanités digitales

Olivier Le Deuff préfère l’appellation « humanités digitales » qui n’est pas un anglicisme, mais un latinisme. Digital vient de digit, le doigt, celui qui permet de compter (on retrouve l’idée de numérique, d’itération, de calculabilité des données), de pointé (appelé l’index, référence d’autant plus frappante).

Cette expression fait à merveille le lien entre les techniques du chiffre (algorithmique) et de la lettre (documentation). Ainsi les humanités digitales seraient « une poétique de la main tendue entre la lettre et le chiffre, entre le savoir et le faire, entre l’homme et la technique »[^1]. Il se garde volontairement d’utiliser l’expression « homme-machine », trop spécifique dans ce contexte vu l’ampleur des problématiques soulevées par les humanités numériques.

« Quelle que soit notre définition de la culture, nous pouvons nous accorder sur le fait qu’elle est liée à l’écriture, sinon grandement portée par elle. Dans un registre littéraire, la culture est faite de romans, de commentaires de ces œuvres, de relectures, etc. L’écriture conditionne aussi les mathématiques, la physique, le fonctionnement, le mode d’emploi de nos machines, de nos logiciels, les enregistrements (films, musique, etc.), tout en évoluant avec ces inventions et avec l’usage que nous faisons d’elle. »[^2]

Pratiques

La pratiques du champ des humanités numériques est divisées en trois sous-disciplines :

  • digital humanities : croisement entres les approches subjectives (aesthesis) des humanités (SHS, arts) et les approches objectives des sciences exactes (mathesis universalis) afin de dépasser cette séparation ;
  • digital methods : études des logiciels, des applications et interfaces de programmation (API) ;
  • cultural studies : traitement massif de données en vue de les valoriser (sémantisation, diffusion).

🔗 la donnée 🔗 base de données

Ces pratiques portent sur des corpus de texte, de (base de) données. Cela consiste autant en une étude de l'humain par le numérique, qu’une étude du numérique par les humanités. Il pose en effet de nombreuses problématiques.

🔗 espace numérique

Limites

Le fait d’extraire une étude en science humaine de son champ ou une œuvre d’art de son support les dénaturent. Le numérique place l’œuvre en dehors de l’espace et du temps ce qui nous fait perdre des notions fondamentales interactives entre une personne et un objet. Une visualisation de données n’est pas un « medium de véracité », mais une « forme de sensibilité » interchangeable.

Les humanités numériques sont comme une béquille numérique pour des disciplines qui se sont peu ouvertes aux usages numériques parmi les SHS. Pour autant, de nombreuses disciplines scientifiques, du côté des lettres comme du côté des chiffre, se sont appropriées ces outils. Aussi, ces deux bords que les humanités numériques réconcilient dans leurs pratiques n’ont pas attendu la transdiscipline pour travailler en interdisiplinaire. Des économistes s’emparent largement des théories philosophiques.

Attention à garder un œil critique sur le numérique, sur le modèle économique qu’il impose au monde, mais aussi au microcosme de la recherche.

[^1]: Olivier Le Deuff, Le temps de humanités digitales, 2014 [^2]: Éric Guichard, Les humanités numériques n’existent pas, 2019

économie documentaire des réseaux sociaux

id : 20200625095558
dernière édition :
type : processus
mots-clés : Olivier Le Deuff, Antonio Casili

Ainsi on retrouve des fiches de toutes les formes sur les réseaux sociaux. Tout le monde peut commenter, annoter (like, commentaires), partager et indexer (tags, libellés) ce qui est une véritable fiche documentaire, rangée dans la base qui forme le profil utilisateur.

🔗 fiche comme modèle de données 🔗 traces numériques

« On peut également noter une volonté de renouer avec les cartes de visite sur les réseaux Instagram ou Snapchat qui permettent d’échanger de façon interactive des profils sous forme de cartes à jouer avec un décorum et un symbole de type Qrcode pour aller découvrir le compte de la personne. L’objectif est de réduire le profil à une simple carte à consulter »[^1]

Sur ces fiches on retrouve du texte, des images, des icônes (emojies), des liens hypertextes, soit un outil de récolte de données et métadonnées : la fiche est le croisement entre la communication d’un utilisateur et la réactions des autres vis-à-vis de cette information. Les algorithmes dressent ainsi un index (« base de données des intentions »[^4]) quand les utilisateurs voient un profil.

« La gestion ds identités numériques laisse entrevoir la constitution d’un pan-catalogue des individualités humaines, ouvert à l’indexation par les moteurs de recherche, et pose ainsi la question de la pertinence des profils humains. »[^2]

La stratégie informationnelle, documentaire, a pour fin l’analyse sociale. C’est pourquoi les réseaux sociaux vont jouer sur l’économie de l’attention, envoyer des notifications pour le shoot de dopamine, mettre en place un design incitatif, une interface centrée sur l’interaction.

🔗 théorie du nudge

Analyse des contenus

L’analyse des personnes s'effectue par l’analyse des contenus (qui renseignent les algorithmes sur ces mêmes personnes). Avec la reconnaissance optique de caractères, des visages, ou plus simplement les analyses d’humeur, de sujet, il est possible d’obtenir de nombreuses informations sur un post.

Analyse personnelle

Les algorithmes n’ont pas la finesse pour analyser le comportement d’une personne, mais d’une masse, sachant qu’elle va déterminer le comportement personnelle. À cette masse catégorisée, indexée, on va proposer un contenu dans une perspective marchande (techno-économique[^3]), le digital audience labor.

« les médias sociaux vendent des bases de données personnelles renseignant les préférences et les comportements de portions de leurs publics à des annonceurs qui les achètent. »[^5]

Ce contenu peut être publicitaire, mais la plupart du temps il s’agit d’autres posts, souvent du même registre (filter bubble, bulle d'information) et plus rarement d’un registre voisin.

En analysant les groupes et en y plaçant les personnes, les réseaux sociaux sont capables d'identifier les contenus en les analysant, mais ils se basent aussi sur les informations qu'ils ont de la personne qui a posté le contenu et les informations des personnes qui interagissent avec ce contenu. En donnant accès au like, au dislike ou à d'autres formes de métadonnées, on entraîne l'algorithme à savoir où nous nous situons dans la population et où il peut venir nous proposer du contenu pour valider ou préciser cette position.

graph TB
	internaute[internaute fidelisé et actif]
	externe[entreprise externe]
	interface(interface active et personnalisée)
	donnees(production de données)
	algorithmes{{algorithmes}}
	marchandisation{{marchandisation}}
	personnalisation{{personnalisation}}
	publicite{{publicité}}
	
	internaute --> donnees
	donnees --> interface
	donnees --> algorithmes
	algorithmes --> personnalisation
	algorithmes --> marchandisation
	personnalisation --> interface
	interface --> internaute
	interface --> publicite
	publicite --> marchandisation
	marchandisation --> externe

Le placement est précis : nous savons que les réseaux sociaux sont capables de déterminer le genre, la sexualité, les appartenances politiques et culturelles d’une personne. C’est une ouverture à l’astroturfing : désinformation populaire (propagande) basée sur un traitement algorithmique.

🔗 ideologie big data la vérité que nous enseigne le big data

Éditorialiser une personne

🔗 éditorialisation

« Pour qu’une personne existe dans l’espace numérique, elle doit avoir un profil sur Facebook, sur Twitter, sur LinkedIn ou sur une autre plateforme qui puisse l’identifier et la rendre visible »[^6]

[^1]: Olivier Le Deuff, La fiche entre économie informationnelle et attentionnelle, 2019 [^2]: Olivier Ertzscheid, L’homme est un document comme les autres : du World Wide Web au World Life Web, 2009 [^3]: expression de Éric Sadin [^4]: John Battelle, The Database of Intentions, 2003 [^5]: Antonio Casili, Qu'est ce que le gigital Labor : Travail, technologies et conflictualités, 2015 [^6]: Marcello V.R. Qu'est-ce que l'éditorialisation?, 2016

écrit et oral

id : 20200903113405
dernière édition :
type : inscription
mots-clés : Jack Goody, Yves Jeanneret

« L’énonciation orale […] est toujours un acte circonstanciel, interpersonnel et non strictement reproductible. L’écriture est la possibilité du jeu de l’écriture sur la langue »[^1] (p.9)

« Le calembour est possible oralement, pas l’anagramme. […] L’écriture ne reproduit pas seulement le flux de la parole, elle en permet la dissection »[^1] (p.10)

Formaliser le savoir

L’écriture permet de manipuler le discours et tend ainsi à l’objectiver[^3]. L’écriture n’est pas une « stricte phonographie », mais permet « d’ouvrir la voie à un développement critique et créateur du savoir »[^1] (p.9).

🔗 grammatisation

« une société orale n’est pas dépourvue de d’esprit critique mais dépourvue des moyens de se constituer une tradition critique »[^1]

Cet effet se répand dans la culture d’une société. Yves Jeanneret paraphrase[^5] ainsi Jack Goody au sujet des sociétés dotées d’une littératie 🔗 : ce sont « les sociétés qui connaissent un état de développement de l’écriture influençant toute forme de communication, y compris non écrite ».

Autorité de l’écrit

Cette tradition est nécessaire pour pratiquer une discipline comme la philosophie qui se nourrit des écrits des pairs et anciens pour descendre vers les nouveaux. On compte aussi sur l’écrit comme preuve, avis scientifique : document. L’écrit applique ainsi à la langue une dimension politique : des institutions (écoles, Académie…) font autorité sur l’écrit et décident par extension de ce qui est digne d’être parlé ou non.

🔗 document

« Ce qui est jugé important ne passe plus par la parole. La parole n’est plus que conversation, échange anodin. Elle n’est dans notre société jamais en rapport avec la vérité et la preuve. »[^4]

Mythe du Phèdre

Platon et rapporte un dialogue de son maître, Socrate, qu'il entretient avec Phèdre. Socrate vient à parler de Theut, dieu égyptien qui inventa en premier la science des nombres (l’algèbre, la géométrie, etc.) puis en second l’écriture :

« Elle ne peut produire dans les âmes, en effet, que l'oubli de ce qu'elles savent en leur faisant négliger la mémoire. Parce qu'ils auront foi dans l'écriture, c'est par le dehors, par des empreintes étrangères, et non plus du dedans et du fond d'eux-mêmes, que les hommes chercheront à se ressouvenir. Tu as trouvé le remède [pharmakon], non point pour enrichir la mémoire, mais pour conserver les souvenirs qu'elle a. Tu donnes à tes disciples la présomption qu'ils ont la science, non la science elle-même. Quand ils auront, en effet, beaucoup appris sans maître, ils s'imagineront devenus très savants, et ils ne seront pour la plupart que des ignorants de commerce incommode, des savants imaginaires [doxosophoi] au lieu de vrais savants. »[^2]

[^1]: Jack Goody, La Raison graphique, 1979 [^2]: Platon, Phèdre (274e-275), traduction de Mario Menier [^3]: Jean-Marie Privat, Sur La Raison graphique. La domestication de la pensée sauvage de Jack Goody, 2018 [^4]: Raphaël Pividal, La Maison de l’écriture, 1976 [^5]: Yves Jeanneret, Yves Chevalier, La physionomie des systèmes : diagrammes et représentation, 2009

écriture

id : 20210406141809
dernière édition :
type : inscription
mots-clés : Samuel Goyet, Jack Goody

L’écriture est « l’inscription de signes sur un support »[^1] (p.43). Elle a trois pans :

  • sémiotique grâce à des signes « observables, interprétables et analysables »
  • technique grâce à « la mise en œuvre d’un savoir-faire technique d’altération (l’inscription) d’une matière (le support) » dans le domaine des architextes 🔗
  • communicationnel car elle « produit un objet observable […] qui organise une situation de communication »

« ne présupposons pas que l’écriture est la consignation volontaire d’un discours et qu’elle ne s’adresse qu’à d’autres humains. […] l’écriture comme consignation volontaire de la pensée par un sujet rationnel, à destination d’autres sujets humains rationnels, est un cas particulier de ce phénomène qui recouvre bien d’autres modalités »[^1] (p.44)

L’écriture est une « technologie de l’intellect »[^2] permettant de structurer la connaissance 🔗 et ainsi notre manière d’appréhender le monde.

On accorde également une facette sociale à l’écriture de par sa technicité. L’écriture n’est pas neutre et mobilise des enjeux institutionnels, d’apprentissage, de maîtrise. L’écriture se partage, mais peut aussi exclure des individus (non maîtrise, impossibilité d’écrire). Elle est aujourd’hui industrialisée.

L’écriture est composite, composée des supports, outils et techniques de sa communauté d’utilisateurs pour représenter une variété de savoirs.

« Elle permet de lier les multiples dimensions d’un phénomène, de le comprendre non pas dans son intégralité mais dans la façon dont ces différentes logiques se croisent et s’hybrident »[^1] (p.45)

Écriture en informatique

« Il ne peut y avoir d’écriture que s’il y a une interprétation et une lecture faite par un humain »[^2] (p.141)

« une modification du système d’écriture est aussi une modification de nos structures de pensée […] l’informatique introduit dans l’histoire de l’écriture un mouvement d’abstraction, dû à la formalisation du calcul et à la rupture sémiotique entre inscription et affichage »[^1] (p.50)

Ainsi, l’écriture sur ordinateur appartient à un autre domaine technique, celui du calcul et donc de l’inscription computationnelle 🔗.

[^1]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^2]: Jack Goody, La Raison graphique, 1979

écriture technique

id : 20210608155755
dernière édition :
type : documentation

La qualité principale d’un document technique est sa clarté. Elle s’anticipe via plusieurs dispositifs, limitant l’effort des rédacteurs et favorsant la recherche d’informations.

Formes d’expression des instructions

Pour une même instruction, il est possible de l’exprimer de différentes manières, avec différentes modes d’écrtiure technique 🔗.

Choix des termes

Les choix lexicaux dans une documentation requièrent certaines attentions pour qu’il soit accessible à un grand nombre de personnes, mais qu’il puisse également couvrir le domaine que le document doit couvrir.

Corinne Grosse[^2] (p.52) dresse une liste de critères d’expression :

  • lexique : Éviter l’utilisation de termes flous, simplifiant une notion, entraînant des ambiguïtés, exemple, « don’t say ‹ put › when you mean ‹ install › »[^1]. Il faut aussi utiliser des synonymes pour décliner le vocabulaire et ainsi fluidifier le texte.
  • terminologie : Dresser une liste finie des verbes et noms du domaine utilisés dans la documentation, selon le domaine, d’après des documentations existantes.
  • grammaire : Exemple, éviter la double négation (« ne pas éviter de ») du passif (« le bouton doit être pressé »).
  • sémantique : Exemple, utiliser le verbe actif (« étudier le ») plutôt que le verbre « faire » (« faire l’étude de »).

Les phrases doivent être courtes et leur construction simple. Ainsi, elles sont plus claires et peuvent être traduites à l’aide d’un traducteur automatique[^1].

Pour faire comprendre une information complexe 🔗, il faut la présenter de différentes manières (par différents dispostifs) pour faire saisir sa logique[^3] (p.14).

[^1]: Alexandra White, Moving beyond empathy: a11y in documentation, 2020 [^2]: Corinne Grosse, Flore Barcellini, Patrick Saint-dizier, Vers la conception d’un outil d’assistance à la rédaction technique, 2012 [^3]: Ian Sommerville, Software Documentation, 2001

EDI, environnement de développement intégré

id : 20210303170947
dernière édition :
type : processus
mots-clés : outil

Un EDI (Environnement de Développement Intégré) est un logiciel de programmation. Il intègre de nombreux outils facilitant et assurant le travail des programmeurs en épousant toute la complexité de l’environnement de développement 🔗. Ils sont capables de compiler/interpréter 🔗 une arborescence de fichiers pour y analyser différents langages, mais aussi y trouver des outils de programmation 🔗 à exécuter. Le tout afin d’aider les programmeurs dans leur travail.

Texte

Un EDI propose les même fonctionnalités qu’un éditeur de texte, sans en être. Il propose comme de nombreux éditeurs de texte des aide à la lecture et à l’écriture :

  • coloration syntaxique 🔗
  • expression régulières (regex)
  • pliage des blocs de code
  • table des structure de contrôle 🔗
  • suggestions de saisie (selon un dictionnaire défini préalablement et/ou au fur et à mesure de la saisie)

On parle parfois d’« éditeurs de code » pour les logiciels les plus avancés sur ces outils de lecture. Toutefois les EDI vont encore plus loin. Ils proposent une série de fonctionnalités aidant à la programmation et nécessitant une analyse réticulaire (suite à une compilation/interprétation 🔗 du code) :

  • versionning 🔗 (connexion avec l’utilitaire Git et analyse des fichiers dans le répertoire .git)
  • refactoring 🔗 (ex : trouver une variable 🔗 en différents contextes du code source et modifier son appel si la déclaration est modifiée)
  • autocomplétion, correction (suggestions de saisie pertinente en fonction du contexte de saisie, notamment l’encapsulation 🔗, et non seulement de la saisie en cours)
  • test (de tout ou partie du programme)
  • documentation intégrée 🔗 (des formules et outils utilisés)

Outils de programmation

Les boîtes à outils programmables 🔗 reposent sur différents environnements d’exécution 🔗 (Python, NodeJs, Ruby…) dont le terminal est l’interface universelle. Ce même terminal peut être affiché dans les EDI pour executer ces programmes. Les EDI permettent aussi de profiter d’une interface graphique pour lancer ces outils pour lesquels ils génère un menu.

Les EDI acceptent généralement eux-même des extensions 🔗 servant d’outils de programmation supplémentaires.

Offre

Si les éditeurs de texte sont pour une très grande majorité gratuits, les EDI professionnels sont assez chers. JetBrains fournit sans doute les meilleurs outils du marché pour une centaine d’euros par an.

JetBrains propose un EDI spécialisé pour différents environnements de développement 🔗. Ainsi, le logiciel ne permet que de compiler 🔗, analyser et donc éditer un langage en particulier.

EDI Environnement de développement Propriétaire
Visual C++ C++ Microsoft
Visual Studio Code NodeJs Microsoft
RubyMine Ruby JetBrains
PHPStorm PHP JetBrains

édition numérique

id : 20200707085937
dernière édition :
type : architecture
mots-clés : Arthur Perret, Antoine Fauchié, Macello V.R., Bruno Bachimont, Samuel Goyet

L’édition est une chaîne de traitement documentaire, un processus qui accompagne l’objet intellectuel document 🔗 par des étapes successives. Les techniques numériques permettent d’automatiser certains de ces processus, mais aussi d’intégrer nos documents sur de nouveaux éléments (ex : diagrammes interactifs), pour de nouvelles manières de lire et apprendre.

« Si la langue anglaise fait la distinction entre l’édition en tant que filière (publishing) et l’élaboration effective du document (editing) […] le terme français d’édition a acquis une certaine polysémie. […] Éditer, c’est orchestrer l’élaboration du document. Dans le contexte de cet article c’est la seconde dimension qui nous intéresse : éditer au sens de créer et manipuler des fichiers ; éditeur au sens de logiciel d’édition ; édition au sens de pratiques d’écriture, entre conception, rédaction et programmation »[^1]

L’écriture numérique possède certaines qualités 🔗 qui font d’elle un matériau malléable auquel on applique une variété d’outils. Ils permettent de la

  • capter (flux en ligne, via une API 🔗),
  • former (feuilles de style 🔗, templating, générateurs de sites statiques).

Ainsi, le document numérique a son propre univers d’édition que l’informatique permet largement d’automatiser. On peut parler de « programmation éditoriale » comme on parle d’« éditeur au sens de logiciel d’édition ; édition au sens de pratiques d’écriture, entre conception, rédaction et programmation »[^6].

🔗 métier d'éditeur

« il ne s’agit pas seulement de choisir, de légitimer, de mettre en forme et de diffuser un contenu, mais il s’agit aussi de réfléchir à l’ensemble des techniques que l’on va utiliser ou créer [… et] aux contextes de circulation produits par l’espace numérique »[^4]

🔗 espace numérique

Étapes

Tout au long du processus d’édition numérique, lecture et écriture, conception et diffusion se confondent. L’informatique oblige à entretenir une architecture pour poursuivre le processus d’édition sans friction. On pourrait parler de chaîne éditoriale, voire de système éditorial, « car sa structure est non-linéaire »[^10].

Écrire → Entreposer, regrouper → Mettre en page → Fabriquer → Diffuser.

« La finalité n’est plus de retrouver des documents, mais d’en produire de nouveaux, à l’aide des ressources retrouvées. On passe ainsi de l’indexation pour la recherche à l’indexation pour la publication. »[^7]

Éditorialisation

« l’éditorialisation est une instance de mise en forme et de structuration d’un contenu dans un environnement numérique »[^8]

« L’éditorialisation est une partie de la chaîne du texte, où différents acteurs spécialisés – et souvent différents de l’auteur du texte : typographes, correcteurs, éditeurs, imprimeurs… – interviennent sur le texte en le transformant. En cela, l’éditorialisation est intimement liée au texte et à sa matérialité »[^9] (p.55)

🔗 editorialisation 🔗 instance de mise en page

Diffusion et distribution

Elle se fait en général sur le web : il faut choisir les formats d’export que vont rencontrer les internautes.

« Publiés sur le web, les textes numériques sont destinés à être lus autant par des humains que par des machines. Ainsi, éditer un livre numérique ne consiste plus seulement à travailler sa mise en forme, mais requiert en premier lieu de le structurer selon un balisage sémantique. »[^5]

Le document numérique s’inscrit également dans un réseau 🔗. Antoine Fauchié a entièrement travaillé son mémoire, puis sa thèse à l’aide d’outils numériques et de plateformes comme Git (dont les commits sont relancés sur Twitter).

🔗 formats de fichier numériques

Dépendances

🔗 dépendances logicielles

Ce processus dépend d’une série plus ou moins importante de logiciels ou de programmes rassemblés.

« Plutôt que de faire porter la continuité d’une chaîne d’édition sur la maintenabilité d’un ou plusieurs logiciels par des sociétés privées ou des communautés centralisées, un système modulaire repose sur l’assemblage de plusieurs programmes, autonomes et connectés »[^2]

[^1]: Arthur Perret, Matière à pensées. Outils d’édition et médiation de la créativité, 2018 [^2]: Antoine Fauchié, Vers un système modulaire de publication : éditer avec le numérique, 2019 [^4]: Michael E.S, Macello V.R., Pratiques de l'édition numérique, 2014 [^5]: Marcello V.R, Nicolas Sauret, Antoine Fauchier, Margot Mellet, Écrire les SHS en environnement numérique. L’éditeur de texte Stylo, 2020 [^6]: Arthur Perret, Matière à pensées : outils d’édition et médiation de la créativité, 2018 [^7]: Bruno Bachimont, Nouvelles tendances applicatives: de l’indexation à l’éditorialisation, 2007 [^8]: Marcello V.R. Qu'est-ce que l'éditorialisation?, 2016 [^9]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^10]: Florian Harmand, Arthur Perret, Former à la notion de réseau par la conception et l’interprétation : l’atelier Reticulum, 2021

éditorialisation

id : 20200621084631
dernière édition :
type : processus
mots-clés : Macello V.R., Bruno Bachimont

« L’éditorialisation est l’ensemble des dynamiques qui constituent l’espace numérique et qui permettent, à partir de cette constitution, l’émergence du sens. Ces dynamiques sont le résultat de forces et d’actions différentes qui déterminent après coup l’apparition et l’identification d’objets particuliers (personnes, communautés, algorithmes, plateformes…). »[^7]

🔗 espace numérique

L’éditorialiste relate des faits en introduisant sa propre opinion. On retrouve ce geste dans l’éditorialisation numérique telle que la production de contenu ou l’interaction d’humains comme une manière d’interpréter le monde (donner du sens).

Dispositifs

Un contenu inscrit dans un fichier numérique est abstrait[^1] tandis que sa mise en forme dépend de logiciels qui vont permettre de réaliser son éditorialisation soit « l’ensemble des pratiques d’organisation et de structuration de contenus sur le web »[^2] :

« ensemble des appareils techniques (le réseau, les serveurs, les plateformes, les CMS, les algorithmes des moteurs de recherche), des structures (l’hypertexte, le multimédia, les métadonnées) et des pratiques (l’annotation, les commentaires, les recommandations via les réseaux sociaux) permettant de produire et d’organiser un contenu sur le web »[^6]

Ce sont ces « dispositifs technologiques qui déterminent le contexte d’un contenu et son accessibilité »[^2]. Ces logiciels permettant d'appréhender le texte sont des « super-structures qui déterminent les conditions de l’accès à l’information »[^3].

🔗 interface

Contexte se lit ici littéralement, comme ce qui accompagne le texte.

Dans l’espace

Éditorialiser, c’est produire de l’espace numérique, donner la capacité d’exister à un contenu ou une personne : « dans l’espace numérique, un objet doit être connecté et mis en relation avec les autres objets pour exister »[^6]. Toutefois, l’éditorialisation ne se produit pas dans un espace numérique général, mais dans un « environnement numérique particulier »[^6].

Pour se mouvoir dans cet espace, ne pas le subir, mais contrôler ses mouvements et sa place, il est nécessaire de comprendre les enjeux (acteurs, dispositifs) du numérique par la littératie.

🔗 littératie numérique

Caractéristiques

On lui distingue cinq caractéristiques à l’éditorialisation[^6] :

  • processualité : « Tout processus d’éditorialisation est toujours en cours ; il est toujours dans une dynamique de mouvement », il est en permanence remis en question (versions d’écriture, re-publication, déplacement dans les résultats de recherche, bug etc.) 🔗 processualité éditoriale
  • performativité : « L’idée de performativité se réfère au fait qu’une action particulière produit quelque chose qui n’était pas prévu – qui n’était pas prévisible – avant ladite action » : l’éditorialisation est justement un « processus ouvert » et créer ses propres normes, modèles d’utilisation en vue d’opérations. « L’éditorialisation est un acte performatif dans le sens où elle tend à agir sur le réel plutôt qu’elle ne le représente. »
  • ontologique
  • multiplicité
  • collectivité

Indexation et combinaison

L’éditorialisation a une dimension culturelle, inscrite dans l’espace et le temps. Elle n’est pas simplement le fruit de dispositifs, mais d’une structure en mouvement perpétuel.

« l’indexation fine du contenu permet de ne retrouver que les segments concernés par la recherche d’information et de paramétrer l’usage de ces segments. »[^5]

[^1]: voir la fiche 🔗 qualités de l'écriture numérique [^2]: Michael E.S, Macello V.R., Pratiques de l'édition numérique, 2014 [^3]: Louis-Olivier Brassard, Infobésité avant la lettre, 2013 [^4]: Macello V.R., La fin de l’autorité ? Pour une philosophie politique du web. [^5]: Bruno Bachimont, Nouvelles tendances applicatives: de l’indexation à l’éditorialisation, 2007 [^6]: Marcello V.R. Qu'est-ce que l'éditorialisation?, 2016 [^7]: Louis-Olivier Brassard Qu’est-ce que l’éditorialisation ?, 2020

effet de bord

id : 20210109130837
dernière édition :
type : programmation
mots-clés : technique

Une expression est dite « à effet de bord » (avec effet secondaire) si elle affecte autre chose que son environnement local, interne. Ainsi, affecter une variable au niveau global est un effet de bord.

var y = 5; // effet de bord

(function () {
    y += 2; // effet de bord
    x = 5; // PAS effet de bord
})();

Souvent, ces effets nuisent à la cohérence du programme en aboutissant à des comportements imprévus (exécutions implicites augmentant la complexité du programme 🔗), voire des défaillances en cascades. Ces bugs sont souvent liés, par exemple, à une mauvaise appréhension de la portée des variables 🔗, à une incrémentation (accroissement d’une valeur par étapes successives) imprévue dans le comportement du logiciel 🔗.

La programmation fonctionnelle 🔗 cherche à minimiser les effets de bords en les encapsulant au sein de monades.

Electron

id : 20210705120100
dernière édition :
type : undefined

Electron est un framework 🔗 permettant de développer des applications 🔗 mutliplateformes grâce aux technologies du Web : HTML, CSS et JavaScript. Pour cela, le logiciel compte sur le puissance de calcul de NodeJs et le moteur de Chromium. Le premier compile des instances du second auxquels sont ajoutés des fichiers source HTML, CSS et JavaScript pour générer son interface et des fichiers CommonJS pour gérer ses processsus.

L’avantage d’un tel outil est de pouvoir compiler le même code source pour permettre aux utilisateurs de tous les systèmes d’exploitation de faire fonctionner l’application. Le moteur graphique de Chromium épargne aussi aux développeurs la lourde tâche de programmer les éléments et intéractions de l’interface à l’aide de bibliothèques 🔗 complexes[^1]. Electron permet ainsi à un développeur d’assumer seul le travail de développement et de maintenance tout en s’adressant à un large public d’utilisateurs. Il faudra néanmoins rester attentif à coller aux différentes expériences utilisateurs (propres à chaque plateformes), à limiter la puissance nécessaire à l’execution (Chromium est déjà gourmand) et à veiller au respect des recommandations de sécurité.

Critiques

Une applications Electron n’est pas « native ». Elle n’intègre pas les éléments propres au système d’exploitation (ni visuels, ni leurs intéractions…)[^2], et n’est pas compilée 🔗 : les fichiers source ajoutés à Chromium sont interprétés à chaque execution. Il y a d’abord une charge sur l’utilisateur, confronté à une interface étrangère à son écosystème de travail général et ensuite une charge sur la machine, pour assumer les lourds calculs et la taille du logiciel (de minimum 200 Mo, poids de Chromium). Pour ces raisons, des professionnels qualifient les instances d’Electron de fatwares, logiciels obèses.

« l’un des points qui dérangent le plus à propos d’Electron est qu’il va empaqueter un runtime Web complet dans chaque application, même si un runtime convenable existe déjà sur le système d’exploitation. Chromium comprend plus de 20 millions de lignes de code et il semble que chaque application Electron va empaqueter une copie de cette énorme base de code sous forme de binaire. Cela aura pour conséquence de grossir la taille de votre application et créer un gaspillage de mémoire »[^2]

Ces effets sont emplifiés par la communauté de Electron. Ce sont principalement des développeurs venus du Web. Ils transposent l’obésité du Web 🔗 aux applications de bureau. Il faut au contraire qu’ils responsabilisent leurs implémentations, qu’ils gardent conscience que l’on ne développe pas une applications de bureau comme l’on développe une application web[^1]. Electron reste bien nécessaire pour les développeurs open source🔗 tant il simplifie le portage de projets bénévoles pour une communauté large[^1].

[^1]: Hendrik Erz, On Electron, the Bloated Web, and Trade-Offs, 2021 [^2]: Michael Guilloux, Faut-il utiliser Electron pour le développement d’applications de bureau ?, 2017

empaqueter (bundle) le code

id : 20210314114007
dernière édition :
type : inscription
mots-clés : technique

🔗 chaîne d’édition du code

Lorsque l’on développe un programme, nous allons pouvoir modulariser 🔗 celui-ci. Cela implique de répartir son code source et ses données dans plusieurs fichiers, mais aussi de faire appel à des bibliothèques 🔗. On prendra soin de lier le tout avec des appels hypertextes 🔗 comme ci-dessous pour un bundle JavaScript.

// index.js
import fx from 'functions';
import d3 from 'd3';

function component() {
    document.body.appendChild(fx());
}

Avec un outil comme Webpack, on peut lancer l’empaquetage à partir d’un fichier « racine » (ici index.js). Nous allons alors obtenir un fichier bundle.js, soit l’agrégation du code source de index.js et celui de ses imports, functions.js et d3.js. Il est également possible de joindre d’autres fichiers de données, des feuilles de styles dans ce tout dont on ne peut plus distinguer les parties.

Durant le processus, il est possible d’appliquer des filtres aux fichiers. C’est utile lorsque l’on veut transpiler 🔗 ou minifier 🔗 du code « à la volée ».

Ces opérations sont utiles pour diminuer le nombre de fichiers à appeler et executer durant l’utilisation du logiciel. C’est aussi une perte de lisiblité très importante du code qui devient illisible pour un humain.

émulation

id : 20210420160220
dernière édition :
type : undefined

Un émulateur est un logiciel permettant de simuler du matériel. C’est un logiciel qui imite le fonctionnement du matériel pour devenir le support d’autres logiciels. C’est le cas par exemple, des logiciels permettant de simuler un terminal (et la console qu’il contient). Il existe l’Invite de commandes de Windows et l’application Terminal de MacOs. Ces logiciels imitent l’usage des centrales de commandes disposées dans les salles informatiques et simulent leur contrôle par le biais d’un logiciel.

On peut ainsi imiter une machine depuis une machine ; c’est le principe des machines virtuelles. Cela permet de regrouper sur une même machine différents environnements d’exécution 🔗 ou bien d’en retrouver un pour un logiciel suranné, trop ancien pour qu’il puisse fonctionner sur les machines de l’époque.

encapsulation

id : 20210428230547
dernière édition :
type : programmation
mots-clés : technique

L’encapsulation est le regroupement de données 🔗 et d’instructions au sein de structures de contrôle 🔗. C’est un procédé de masquage de l’information : on évite que les utilisateurs et développeurs puissent y accéder et les modifier de manière détournée (hors de la procédure définie par le développeur) pour implémenter des canaux sécurisés et faciles d’utilisation (gestion des erreurs).

L’encapsulation est généralement réalisée par la gestion de la portée des variables 🔗.

Dans les classes

L’encapsulation est l’un des principes fondamentaux de la programmation orientée objet 🔗. Elle permet de valider des procédures très rigoureuses d’interface des classes (pour disposer un système extensible). L’encapsulation des attributs et méthodes est généralement (Java, C++, PHP…) gérée à trois niveaux :

  • public : par d’encapsulation, la valeur est accessible depuis l’ensemble de l’espace de nom 🔗 ;
  • protégé : les classes héritières peuvent accéder à la valeur ;
  • privé : seules les fonctions internes peuvent accéder à la valeur.

Par exemple, voici une classe PHP ci-dessous qui utilise les trois niveaux de protection. L’ascenseur (getter) get_password permet d’accéder à la valeur privée de l’attribut $id et devient un point de passage obligatoire pouvant comporter différentes opérations de validation.

class User {
    public $id;
    private $password;
    
    public function get_password()  {
        return $this->password;
    }
    
    protected function delete()  { … }
}

encodage du texte

id : 20200717141735
dernière édition :
type : inscription

Le texte brut n’existe pas. D’immenses tableaux (appelés encodings) stockés dans les ordinateurs contiennent toutes les lettres d’un côté, et toutes les combinaisons de 0 et de 1 de l’autre. Or, presque chaque pays a créé son propre tableau, et ces tableaux sont incompatibles entre eux : pour la même combinaison de 0 et de 1, ils donnent un caractère différent voire rien du tout.

🔗 texte brut

Selon les environnements (navigateur web, terminal ou console Python), l’encodage peut être très différent et d’un copier/coller à l’autre, on peut changer plusieurs fois d’encoding. Ainsi, le texte brute, le code, sont encodés et il est crucial de savoir comment pour éviter de perdre de l’information.

Encodage caractères

L’ASCII support les caractères anglais (donc pas les accents) tandis que l’UTF-8 permet de coder tous les caractères.

L’UTF-8 (Universal Character Set Transformation Format, sur 8 bits) est le langage universel : c’est une implémentation de Unicode, un tableau gigantesque qui contient suffisamment de combinaisons pour éliminer les problèmes d’encodage à travers le monde (l’ésperanto informatique).

Problèmes d’encoding

Lorsque l’on a un problème d’encoding c’est que l’ordinateur n’arrive pas à trouver comment afficher le caractère : il n’a pas utilisé le bon tableau. Il faut donc lui indiquer quel est le bon tableau (en supposant qu’on l’on connaisse l’encodage d’origine et l’encodage cible) ou bien transcoder le caractère.

Déclarer encodage

Placer la ligne suivante en haut de certains fichiers permet d’assurer que l’ordinateur sait quel encoding utilisé.

# coding: utf8

Source : http://sametmax.com/lencoding-en-python-une-bonne-fois-pour-toute/

encre des données

id : 20201119142248
dernière édition :
type : modélisation

🔗 visualisation

L’encre des données (data-ink) est un concept développé par Edward Tufte dans son livre The Visual Display of Quantitative Data (1983). Il permet d’établir un rapport entre l’encre (nombre de pixels) utilisée pour un affichage de données et celle utilisée pour effectivement afficher les données. Il convient en effet de trouver un équilibre dans cet affichage afin de ne pas distraire l’internaute, de le détourner du véritable sujet de la page.

Pour équilibrer cet affichage, il est nécessaire d’appliquer le calcul suivant. Le résultat doit être le plus proche possible de 1.

data-ink ratio = encre des données / encre de l’affichage

Ainsi, on limite au maximum les aplats et les tracés inutiles en ne gardant que les repères nécessaires.

Source : https://infovis-wiki.net/wiki/Data-Ink_Ratio

enjeux politiques de l’écriture numérique

id : 20200725133539
dernière édition :
type : undefined
mots-clés : politique

L’écriture numérique est en enjeux politique comme l’écriture de manière générale :

« Nous savons aussi que la maîtrise de l’écrit est un paramètre essentiel de ces rapports de pouvoir, ne serait-ce que parce qu’elle donne la possibilité d’infléchir les orientations de la culture de l’écrit. […] les grandes entreprises du numérique maîtrisent l’écriture, la confisquent à leur manière en nous louant des logiciels, en favorisant des formats de fichier, des protocoles, des modes d’échange en ligne (qui sont écrits), en déformant le monde perçu selon leurs perspectives, parfois appelées algorithmes »[^1]

🔗 la loi du code

« Nous avons donc perdu progressivement la capacité d’écrire dans un langage interprétable par la machine. »[^2]

🔗 problème des logiciels de traitement de texte

[^1]: Éric Guichard, Les humanités numériques n’existent pas, 2019 [^2]: Julien Dehut, En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation, 2018

énonciation éditoriale

id : 20200916105659
dernière édition :
type : inscription
mots-clés : Emmanuel Souchier, Samuel Goyet

🔗 édition numérique

« La théorie de l’énonciation éditoriale repose sur l’idée que tout texte doit être vu pour être lu »[^3] (p.487). Tous les éléments du processus d’édition (génération, mise en page…) d’un texte participent à sa compréhension, sa lecture. Si le texte « premier » n’est fait que de grammaire et de sens, il ne « s’objective qu’à travers l’existence d’un texte second », matériel. L’énonciation éditoriale est le texte « pas uniquement comme texte écrit, mais comme objet ‹ polyphonique ›, objectivé sur un support matériel » par « matérialité du support et de l’écriture, l’organisation du texte, sa mise en forme »[^1]

« Il y a donc une énonciation, en ceci que quelque chose est dit du texte par sa seule image »[^3] (p.487)

Des exemples d’œuvres mettant en évidence cette dualité équilibrée et interdépendante :

  • Cent mille milliards de poèmes de Raymond Queneau (1961) ;
  • Exercices de style de Raymond Queneau (1961) ;
  • Composition n°1 de Marc Saporta (1962).

Au sujet de la typographie 🔗, « son évidente omniprésence masque son existence au point de la faire disparaître et d’en effacer le sens et la fonction »[^1]

Épaisseur du texte

Le texte impose une « résistance physique »[^1], sociale, culturelle. Il adopte un format, une matière, une graphie (mise en page, typographie, illustration) porte un ensemble d’attributs (titre, auteur, éditeur et droits, ISBN), autant d’éléments observables qui plus qu’accompagner le texte le font vivre, lui donne une identité et une connotation qui vient s’ajouter au sens du texte.

Prendre en compte le fond plutôt que la forme du texte, ou l’inverse, sont des « erreur symétrique »[^2] et c’est le risque du texte sur écran.

Le risque est de « voir la détermination technique l’emporter sur toutes les autres »[^2], que le texte soit réduit à son affichage, qu’il soit réduit à une tâche automatique. En effet, on perd de vue l’« épaisseur technique » nécessaire à l’instance du contenu (fond) et de l’interface (forme), déterminée par les architextes 🔗.

[^1]: Emmanuel Souchier, L’image du texte pour une théorie de l’énonciation éditoriale, 1998 [^2]: Dominique Cotte, Écrits de réseaux, écrits en strates. Sens, technique, logique, 2004 [^3]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

environnement de développement

id : 20201224152456
dernière édition :
type : processus

L’environnement de développement se forme autour d’un projet (ou d’une série de projets) logiciel. Il compose l’espace de travail des développeurs, la chaîne de production. Il s’agit autant de la méthodologie de projet que de l’inscription du code. Il encadre la structure du logiciel 🔗 et lui ajoute différents dispositifs présentés ci-après.

L’environnement de développement a pour rôle de rendre le travail des techniciens plus efficient. Il intègre des outils permettent de traiter automatiquement certains fichiers, d’aider à l’inscription du code ou encore de limiter les erreurs. Il ne sert pas nécessairement à accélérer le développement, mais à assurer son efficacité.

Un code plus contraignant à écrire (sel syntaxique, framework…) est un code plus réfléchit ; la vitesse n’est pas nécessairement un critère d’efficience.

Dispositifs

On dresse plusieurs catégories de dispositifs au sein de l’environnement de développement :

  • Intégrations de code
  • méthodologie et documentation de projet (Forges 🔗)
    • Git 🔗
    • Générateur de la documentation
  • éditeurs et outils de programmation, de développement
    • EDI 🔗
    • boîte à outils programmable 🔗

Ces dispositifs laissent tous une trace dans l’arborescence du logiciel. Soit ils intègrent directement le code source (comme les bibliothèques 🔗), soit ils laissent un fichier de configuration sur lequel ils viennent se greffer d’une installation à l’autre (voir tableau ci-dessous). Ce système permet de versionner 🔗 la configuration de l’environnement de développement. Ils deviennent tous en quelque sorte des dépendances du projet qu’il devient facile de repérer et de (re)installer pour les collaborateurs.

Ci-dessous une liste de fichiers (dotfiles) et répertoires cachés contenant des informations relatives à l’environnement de développement. Ils ne portent pas de nom, uniquement une extension, ce qui les rend invisibles sur la plupart des explorateurs de fichiers (dans leur configuration d’origine), mais pas depuis les menus des EDI 🔗.

fichier ou répertoire utilisation
/.vscode configuration de l'EDI 🔗 Visual Studio Code
/.github configuration de la forge 🔗 GitHub
.gitignore liste des fichiers ignorés par l'outil de versionnement 🔗
.eleventy.js fichier de configuration du framework 🔗 "11ty"

Obésité ?

Ces dispositifs viennent pallier de nombreuses problématiques rencontrées par les développeurs pour industrialiser leur métier (production à la chaîne) mais aussi se confronter à des techniques de plus en plus complexes 🔗.

Documentation

Ces dispositifs ont également leur documentation propre, indépendante de la documentation du logiciel 🔗. Il n’est pas utile d’alourdir cette dernière d’explication par rapport à ces dispositifs, sinon en justifiant leur utilisation et en pointant leur documentations respectives.

Deux documents de la documentation logicielle 🔗 permettent d’appréhender l’environnement de développement :

  • la convention de développement 🔗 (à l’usage des développeurs)
  • l’encyclopédie (document passerelle, entre utilisateur et développeur)

Effet sur le travail

Marc-Eric Bobillier Chaumon et Éric Brangier[^1] (p.17) expliquent que l’environnement de développement affecte trois modes de travail :

  • opératoire : « les situations de travail évoluent sur le plan du contenu de la tâche et de leur organisation, ce qui amène les informaticiens à revoir leur manière de structurer leur activité »[^1] (p.17)
  • cognitif 🔗 : « les changements techniques obligent les individus à apprendre d’autres raisonnements de conception et à déterminer de nouveaux modes d’interaction homme-machine »[^1] (p.17)
  • socio-professionnelle : « des comportements sociaux et relationnels […], basés sur la coopération et la négociation »[^1] (p.17), voir ci-après.

Re-organisation sociale

L’environnement de développement affecte aussi bien les conditions de production du logiciel que les condition de travail des collaborateurs.

« l’environnement de développement serait également l’outil qui code en machine les possibilités de transformations socio-organisationnelles. Il serait donc à la fois un objet technique et social »[^1] (p.6)

Les développeurs vont préférer travailler sur des techniques faciles à utiliser et apprendre tout en préférant limiter (grâce à la compatibilité) le ré-apprentissage « qui génère une surcharge de travail, du stress et finalement un rejet du système »[^1] (p.6).

Changer les méthodes et outils de conception peut s’avérer très lourd de conséquences sur la productivité et la qualité des logiciels 🔗 bien que les motivations n’ont rien à voir avec la programmation (marketing, économie…). Cela peut aussi largement améliorer la coopération entre les personnes[^1] (p.14).

[^1]: Marc-Eric Bobillier Chaumon et Éric Brangier, Évolutions de l’activité et de l’organisation du travail lors du changement d’environnement de programmation chez les informaticiens, 2000

environnement de développement logiciel hypertextuel

id : 20210130151200
dernière édition :
type : architecture

L’environnement de développement 🔗 des logiciels est hypertextuel. Il s’agit des liens au sein de son arborescence, avec sa documentation, entre ses documentations annexes et avec tous les autres outils de la chaîne d’édition du code source 🔗 ; les liens hypertextes sont partout.

Le préfixe « hyper » 🔗 ne suggère pas la puissance de ces textes source (prose ou code). Ce serait fétichiser 🔗 leur impact réel sur le système. Toutefois, il permettent aux développeurs de profiter d’un système combinatoire 🔗 basé sur l’édition de texte, avec toutes ses qualités 🔗.

Ci-après nous présentons deux exemple pour envisager l’hypertexte dans l’environnement de développement. D’abord horizontalement, entre les fichiers de l’arborescence et ensuite verticalement, par le biais d’un scanne de l’arborescence par un outil de développement.

Horizontalement

Pour maîtriser le flot de contrôle 🔗 au sein des logiciels, on recours à des techniques dans la logique de l’hypertexte 🔗. Les liens sont formalisés autrement, via à des mots-clés et des chemins de fichier, des adresses web. L’exemple suivant permet d’appeler les modules app et BrowserWindow pour le framework Electron. La source de ce même framework est stockée dans le répertoire node_modules.

const {
    app // application's event lifecycle, events
    , BrowserWindow // application's windows
} = require('electron');

Verticalement

Ci-dessous on instancie le second module BrowserWindow depuis une fonction createWindow. Elle est commentée dans un travail de documentation du code 🔗, lequel est utile par l’intégration de l’outil JSDoc. Cet outil va intégrer le code dans une page web et l’indexer dans l’API 🔗 par un lien hypertexte dans l’ancre est le nom de la fonction.

/**
 * Open a window for the app.
 * @param {string} title - The title of the window.
 */

function createWindow (title) {
    const window = new BrowserWindow ({
        width: 800,
        height: 600,
        title: 'Masteï'
    });

    window.loadFile('template/index.html')
}

espace

id : 20200719212204
dernière édition :
type : architecture
mots-clés : Marcello V.R.

L’espace est une notion fondamentalement humains tant elle est conditionne notre perception du monde. L’espace est le résultat de la structure des relations entre des objets. Deux philosophes s’opposent et conçoivent différemment la relation entre les objets.

Descartes

Il défini l’espace objectif, homogène : des points sont reliés sans hiérarchie d’aucune sorte.

Foucault

L’espace est un « ensemble de relations entre les objets qui portent des valeurs ». C’est un espace de valeurs qui dans tous les cas suggère un mouvement des objets, un rapport nécessairement inégal entre eux. Même les espaces sont inégaux : « des lieux ont plus de poids que d’autres »[^1]

Cette vision est le fruit d’analyses politiques et phénoménologiques[^1].

[^1]: Marcello V.R., La fin de l’autorité ? Pour une philosophie politique du web.

espace numérique

id : 20200801210302
dernière édition :
type : architecture
mots-clés : Marcello V.R., Bruno Bachimont

🔗 espace

On pense souvent le Web comme un « non espace, un non lieu, une utopie dans le sens étymologique du mot »[^1] : « en aucun lieu ». De par la nature de l’espace numérique on peut oublier que nos actes (ex : l’envoi d’un fichier) ont des conséquences. On oublie les coûts humains, matériels, écologiques du réseau Internet et de son entrée jusque dans nos espaces physiques intimes.

« Il est important de souligner que si nous comprenons le mot ‹ numérique › dans un sens culturel, l’espace numérique est notre espace principal, l’espace dans lequel nous vivons, et pas seulement l’espace du web ou des objets en ligne. »[^2]

🔗 éditorialisation

Si le numérique ne peut être comme matériel, alors il ne peut être politique. Hors il change radicalement notre rapport à l’information.

🔗 enjeux politiques de l’écriture numérique 🔗 digital labor

Effacement

Le numérique « prend une dimension anthropologique, il fait parti de notre condition d’êtres humains »[^3]. C’est ainsi qu’il faut comprendre le numérique, l’étudier et ainsi prévenir le risque qu’il devienne « impensable […] dans nos usages puisque on sera plus ou moins condamnés à ne penser qu’à travers les outils que le numérique a mis en place et donc il se sera effacé à travers les objets qu’il aura contribué à élaborer ».

Le numérique comme technique va avoir cette tendance naturelle à s’effacer au profit des outils et des usages qu’il a permis de créer.

🔗 rapport aux objets techniques

Hybride

Internet n’est pas un espace séparé du monde physique, du réel, mais un espace hybride. Il s’invite dans l’espace pre-numérique (qui précède le monde numérique) via l’implantation récente d’objets interconnectés par le réseau Internet (téléphone, montres, véhicules… ). On ajoute cette hybridation à la densité et la nature hyperactive du numérique qui définissent cet espace.

Fragmenté

Le numérique est un espace que l’on ne peut toucher mais qui est bien réel, bien qu’il soit aussi fragmenté : nous sommes chacun derrière nos écrans et l’existence de chaque objet tient aux liens qui le raccrochent à une réalité, comme celle d’un moteur de recherche.

🔗 hyper

« [par rapport au papier, l’ordinateur comme outil d’écriture découple] trois espaces nettement distincts sur l’ordinateur : celui de la saisie (le clavier), celui de l’affichage (l’écran) et celui de l’enregistrement (la mémoire) […] C’est dans cet écart que se glisse et se manifeste la supposée dématérialisation »[^4]

Le Web est fragmenté en de nombreux endroits, en de nombreux sites, eux-mêmes fragmentés en pages, elle-même fragmentées en différents fichiers réunis par différents protocoles (par exemple link pour le CSS, include entre des fichiers PHP). L’envoi des pages se fait entre un client et un serveur 🔗 qui échangent non pas un flux continu de données, mais des paquets qui sont décomposés d’un côté puis réceptionnés, recoupés, regroupées à l’arrivée. Ces paquets arrivent sur différents terminaux qui ont chacun leurs différentes couches logicielles par lesquelles passent les informations avant d’arriver sur des interfaces elles-mêmes morcelées.

🔗 architexte

« L’environnement numérique est prescriptif, car il détermine la forme des contenus qu’il héberge »[^2]

Contrôle

Deux catégories de multinationales contrôlent le monde numérique. Il s’agit autant de la partie matérielle (hardware) que de la partie logicielle (software) :

GAFAM : Google, Amazon, Facebook, Apple et Microsoft BATX : Baidu, Alibaba, Tencent et Xiaomi

[^1]: Marcello V.R., La fin de l’autorité ? Pour une philosophie politique du web. [^2]: Marcello V.R. Qu’est-ce que l’éditorialisation?, 2016 [^3]: Bruno Bachimont, Rhétorique de l’intelligibilité, vers des humanités du numérique, 2020 [^4]: Pascal Robert et Nathalie Pinède, Le document numérique : un nouvel équipement politique de la mémoire sociale ?, 2012

extension et greffons

id : 20201201135325
dernière édition :
type : architecture

On parle d’extension (add-on) ou de greffons (plugin). Les deux permettent d’ajouter des fonctionnalités à un logiciel receveur. Contrairement aux extensions, les greffons sont des applications à part entière, dites standalone. Ainsi, elles n’ont pas de dépendances.

🔗 dépendances logicielles

fétichisation des programmes

id : 20210502094415
dernière édition :
type : programmation
mots-clés : Wendy Hui Kyong Chun, Samuel Goyet, Bruno Bachimont

Grâce à une écriture formalisée par les langages de programmation alphanumériques 🔗, on est tenté de penser la machine comme un humain très docile ; comme si elle allait répondre à tous les ordres parce qu’on le lui a commandé, comme on lui a commandé. Or, il n’en est rien. Penser cela c’est anthropomorphiser par erreur la machine et son fonctionnement, tandis que sa performance (l’étendu de ce qu’elle peut faire) dépasse largement notre influence par le biais des langages de programmation, alors diluée dans les strates logicielles 🔗. L’étendue de cette performance échappe d’ailleurs aux développeurs. Cantonnés à des paradigmes 🔗 et environnements d’exécution 🔗 divers, notre métier ne consiste pas à prendre le contrôle de la machine mais à développer des interfaces 🔗 sur lesquels d’autres développeurs et utilisateurs viendront s’appuyer.

« voir le code comme subjectivement performatif ou énonciatif, c’est l’anthropomorphiser, le projeter sur la rubrique de la psychologie, plutôt que de le comprendre à travers sa propre logique de ‹ calcul › ou de ‹ commande › »[^1] (Alexander R. Galloway)

Croire que l’on peut donner un but et un désir aux machines c’est en faire des fétiches. On ne peut commander une machine, la « soumettre à notre volonté » par l’écriture (« thélémacentrisme »[^4], p.499).

On peut voir à tord en l’informatique une « réalité comme soumise à des pouvoirs animés dont les buts pourraient être devinés et influencés »[^1] et en faire un fétiche pour ne pas admettre qu’il y a une contingence ou en tous cas un manque de contrôle sur les actions de la machine (par sa matérialité 🔗). On cherche à tord une fausse causalité (on fait une sourcellerie).

Ensourcellement

« on ne peut pas exécuter de code source : il doit être compilé ou interprété […] le code source ne devient source qu'après coup. Le code source est plus précisément une ressource plutôt qu’une source. »[^1]

Le code source d’une document est d’une nature différente de celle du document qu’il génère. Oublier la nécessité de l’interprétation/compilation 🔗 du code source, sa dépendance à l’environnement d’exécution 🔗, c’est l’ensourcellement. Hors, la source du code est un processus est n’est pas fixé dans une série de fichiers de code (« code source »). Il n’y aurait pas de code source à proprement parler, mais des fichiers interprétés pour engendrer une exécution dont ils ne rendent pas compte.

De la même manière, chercher absolument la source fondamentale d’un programme pour finalement dire qu’il n’est finalement qu’une série d’impulsion électrique dans un système mécanique, c’est aussi s’ensourceler. Un programme est à la fois électrique, formalisme et interface graphique sans que l’on doive séparer ces strates pour expliquer le fonctionnement d’un programme.

Sortir le code d’un programme de son contexte d’exécution (ouvrir le programme dans un éditeur de texte plutôt que de l’exécuter) revient à le « désourcifier »[^4] (p.490).

Idéalité computationnelle

Face à l’ensourcellement, Samuel Goyet propose d’opposer l’« idéalité computationnelle » comme l’a théorisé Bruno Bachimont[^3] (p.95), « soit l’indépendance de l’information par rapport à son substrat [support d’existence] matériel »[^2] (p.484). Si les conditions matérielles et opérationnelles (bornant le calcul) importent toujours, on conserve à toutes les strates l’idée que l’informatique est computationnel 🔗, traite du calcul.

[^1]: Wendy Hui Kyong Chun, On ‹Sourcery›, or Code as Fetish, 2008 [^2]: cité par Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^3]: Bruno Bachimont, Arts et sciences du numérique. Ingénierie des connaissances et critique de la raison computationnelle, 2004 [^4]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

feuille de style

id : 20210207120845
dernière édition :
type : inscription

Une feuille de style est ensemble de règles permettant de modifier l’apparence d’une classe d’éléments. Cette apparence affecte consécutivement l’ensemble des objets 🔗 de cette classe. Ainsi, en définissant un visuel pour la classe paragraphe, on modifie le visuel de tous les paragraphes du document.

Ces règles peuvent être établies dans un fichier externe ou bien directement en en-tête du fichier contenant les classes qu’elle affecte. Dans le premier cas, une seule feuille de style peut affecter plusieurs fichiers, tant que ceux-ci répondent au même schéma de données. Un fichier peut également faire appel à plusieurs feuilles de style.

Il est possible de définir des règles relatives à la typographie 🔗, à la couleurs (corps et arrière-plan), à la position (absolues, marges) des éléments dans l’espace du document…

Il existe les feuilles de style CSS (pour les fichiers HTML) et les feuilles de style XSL (pour les fichiers XML).

fiche comme modèle de données

id : 20200624194717
dernière édition :
type : inscription
mots-clés : Olivier Le Deuf

🔗 hypertexte

La fiche est un outil historique d’organisation des connaissances et de l’information. Son étymologie latine (figere) renvoie à ses potentialités de fixer l’information.

Usage

Jean-François Bert cite quelque[^3] usages de la fiche :

  • « la fiche facilite les renvois, rend possible une lecture fragmentaire » : le lecteur est capable d’exploiter les fiches à l’unité ou bien d’en « compiler » plusieurs pour une information plus générale. On donne au lecteur la capacité de diriger sa lecture.
  • elle « sert à multiplier les informations ponctuelles, à les compiler, à les commenter, à les expliciter, à les vérifier et à les corriger, ou encore à les authentifier »
  • « elle engage aussi la question de la visualisation, et de la remémoration » comme un schéma de pensée que l’on pourrait imprimer intellectuellement, la fiche oblige aussi à se rappeler, à réexpliquer une pensée. La fiche est un « travail redondant qui n’est pas fait en pure perte puisque ce doublon pourra, à terme, être reclassé selon un ordre ou une classification différents »[^3]

Format

Il faut voir dans la petite taille de la fiche non pas une limite à imposer à sa mémoire, mais l’opportunité de discipliner son esprit à composer une pensée sur une surface définie ; c’est une épreuve de design.

Jean-François Bert différencie la fiche à « références multiples » et la fiche à « référence unique ». La première, plus grande, est destinée à être classée tandis que la seconde, « à portée de main » peut « être facilement mise de côté »[^3].

Paul Otlet prescrit le format désormais standardisé 125 × 75 mm : « Sur la gauche, le nom de l’auteur et son prénom entre parenthèses. À droite, un chiffre international, tiré de la CDD. Sur la seconde ligne, la date de publication, le titre de l’ouvrage in extenso. Puis viendront les indications de lieu, d’édition, d’impression »[^3].

Numérique

Les posts[^2] des réseaux sociaux sont autant de fiches que s’échangent et partagent les internautes avec de nouvelles formes d’annotations (comme la possibilité de d’ajouter un like, des commentaires). Ces métadonnées sont inscrites en vue d’une re-indexation permanente du contenu.

🔗 économie documentaire des réseaux sociaux

On retrouve aussi la fiche comme fichier, notamment Markdown avec l’entête YAML (YAML Front Matter).

De la pile à la base de données

La notion de « pile » (de fiche) constitue le principe du logiciel HyperCard. L’équivalent informatique de la fiche est l’instance informatique d’objets via une class qui prend l’apparence de formulaires. On y inscrit les données avec un contrôle de la saisie pour les stocker sur une base de données. L’interface de cette dernière prend le plus souvent la forme d’un tableau avec à disposition des outils de tableur pour traiter en masse les objets qui apparaissent sous forme de ligne. Le paradigme de la programmation orienté objet permet de contrôler précisément ce type de système avec une méthode complète pour concevoir, modéliser et programmer ce type d’infrastructure.

🔗 HyperCard 🔗 instance informatique

Analogique Informatique
meuble base de données 🔗
modèle classe
méthode formulaire 🔗
fiche objet 🔗

Les moyens changent, le vocabulaire, les outils, mais l’intention et la méthode demeurent. Ainsi, l’identifiant est un élément fondamental de ce système documentaire : chaque fiche, chaque objet doit pouvoir être précisément nommé et localisé.

Activité humaine

Il y a aussi quelque chose de personnel et compulsif dans le fiche.

« Faire des fiches est une activité humble et répétitive, machinale et parfois compulsive, dans certains cas pathologique. On retrouve une discipline du corps, de la main et de l’attention qui se déploie dans une temporalité mesurée à l’aune de critères quantitatifs » Christian Jacob, préface [^3]

[^1]: décomposer un problème complexe en « sous-problèmes » plus simples [^2]: tweets, cartes Tinder, publications Facebook, Intagram, ou sur un forum [^3]: Jean-François Bert, Une histoire de la fiche érudite, 2019 [^4]: Olivier Le Deuf, La fiche entre économie informationnelle et attentionnelle, 2019

flot de contrôle

id : 20200930183337
dernière édition :
type : programmation

Le flot de contrôle (control flow) est un l’ordre d’exécution des instructions d’un programme tel qu’il est défini par l’inscription des structures de contrôle 🔗.

Pour le code ci-dessous, on fait appel deux fois aux instructions contenues dans la fonction isContainingPairs. La structure for est une boucle qui encapsule deux conditionnelles. La première court-circuite la boucle si le test n’est pas vrai. Le seconde interrompt l’exécution de la fonction (donc de toutes ses instructions) si le résultat du test n’est pas 0. Après l’exécution de la boucle, la fonction retourne la valeur true.

La valeur true est retournée dans tous les cas où la fonction n’a pas été interrompue lors des itérations.

// vérifier si le tableau en paramètre contient des nombre entiers pairs
function isContainingPairs(array) {

	for (i = 0; i < array.length; i++) {
		if (Number.isInteger(array[i]) !== true) {
  			continue; }
	
  		if (array[i] % 2 !== 0) {
  			return false; }
	}

	return true;
}

const one = isContainingPairs([2,16,'hello',4,12]) // true
const two = isContainingPairs([3,2,'bye',7]) // false

Le flot de contrôle peut être modélisé sous la forme d’un ordinogramme 🔗. L’inscription du code 🔗, indenté, permet de se repérer entre les structures de contrôle 🔗 facilitant ainsi la lecture du flot de contrôle.

Raisonnement

Le flot de contrôle décrit pas à pas le raisonnement d’un développeur. Le paradigme de la programmation lettrée 🔗 voudrait que l’on préscrive les instructions dans l’ordre le plus logique pour un humain afin que nous puissions tous saisir intuitivement le raisonnement de nos pairs et ainsi poursuivre leur geste. Il n’est malheureusement pas toujours possible de rester intuitif. Les envrionnements d’exécution 🔗 (et les langages qu’ils exécutent) imposent un ordre dans les déclarations.

Il est possible dans certains langages d’appeler une fonction tandis qu’elle n’est déclarée que plus bas dans le code source. D’autrefois il faudra péniblement déclarer toutes les variables, toutes les fonctions avant de pouvoir enfin présenter à ses pairs la procédure globale. Cette procédure est un modèle 🔗 tel qu’il est suggéré par les noms donnés aux différentes entités qui le composent. On pourrait préférer détailler les éléments de ce modèle en aval pour progressivement faire baisser le niveau d’abstraction. Ça n’est pas toujours possible.

fonctions

id : 20201224102746
dernière édition :
type : programmation
mots-clés : technique, Bruno Bachimont

Ce sont des séquences génériques de calcul, des séries d’instructions. Elles peuvent être répétées, appelées en cascade ou intégrées les unes aux autres et ainsi (re)organisés à volonté, dans une logique combinatoire 🔗.

Une fonction admet les variables 🔗 suivantes :

  • paramètres : liste des intrants d’une fonction, éventuellement avec une valeur par défaut ;
  • intrants (ou entrées) : valeurs intégrées à la fonction, qu’elles soient globales[^1] ou passées en paramètre ;
  • extrants (ou sorties) : valeur retournée par la fonction.

Le mot-clé return permet généralement de mettre fin à l’exécution de la fonction et de retourner une valeur (à stocker dans une variable) que prendra la fonction. Si la fonction ne retourne pas de valeur, on l’appelle une routine (subroutine).

const foo = 5;

function multiplicate(number, multiplicator = 2) {
    return number * multiplicator;
}

On appelle méthodes les fonctions encapsulées dans une classe.

Une fonction est une constante 🔗, ce qui veut dire que dans de nombreux langages, elle peut également être intrante dans une fonction, ou même être passée en paramètre.

Écriture

On écrit en algèbre la fonction f de la manière suivante, qui va permettre de multiplier le nombre x (entrée) par deux :

ƒ(x) = x * 2 tel quel ƒ(4) revient à écrire 8 ; le résultat remplace l’inscription du calcul, « Le propre du calcul est que le contenu ne porte pas sur lui les traces de sa manipulation »[^3].

🔗 transparence référentielle

Dans la plupart des langages de programmation, cette même fonction va s’écrire de la manière suivante :

function f(x) {
    return x * 2;
}

const f = x => x * 2 ;

Usages

On distingue trois usages de fonctions[^2] :

  • Application : obtenir une valeur basée sur le traitement d’entrées ;
  • Procédural : répéter l’exécution d’une séquence d’instructions ;
  • Interface : commander des parties du système grâce aux fonctions proposées par le runtime 🔗.

🔗 fonctions pures

On parle de fonctions d’ordre supérieur (ou callback 🔗) pour une fonction passée en paramètre d’une premières afin d’y être appelée durant la prodécure. Dans l’exemple suivant, la fonction filter prend pour callback la fonction isEven  :

function isEven(v) {
    return v % 2 == 0;
}

let evens = [1,4,12,5].filter(isEven) // [4, 12]

[^1]: 🔗 la portée des variables [^3]: Bruno Bachimont, Le sens de la technique : le numérique et le calcul, 2010

fonctions pures

id : 20201224145634
dernière édition :
type : programmation
mots-clés : technique

🔗 fonctions

Une fonction pure est une fonction pour laquelle on a toujours la même sortie pour les mêmes entrées[^2] et sans effet de bord 🔗 : elle renvoie simplement le résultat de cette opération. Ce sont des éléments très simples du programme, facilement interchangeables, indépendants de l’état extérieur et qui ne peuvent donc muter.

On garanti ainsi la transparence référentielle 🔗.

Exemple

La fonction pure suivante se substitue à sa valeur de sortie, sans autre effet que de renvoyer systématiquement la même sortie pour la même entrée.

function double(int) {
    return int*2;
}

Ainsi, double(4); renvoie 8, indépendamment du contexte, du nombre d’appel, de sa place dans le flux de contrôle[^1].

Inversement, la fonction suivante déclenche l’arrêt du programme si la valeur globale sysIsActive vaut false. Ça n’est donc pas une fonction pure.

🔗 la portée des variables

function double(int) {
    if(!sysIsActive) {
        process.exit();
    }
    
    return int*2;
}

[^1]: Eric Elliott, Master the JavaScript Interview: What is a Pure Function?, 2016

forge

id : 20210111200221
dernière édition :
type : architecture
mots-clés : technique

🔗 environnement de développement

Une forge est un système de maintenance collaboratif permettant de rassembler les productions de différents développeurs afin de les assembler (via des opérations systématiques) pour former un ou plusieurs logiciels.

🔗 versionnement Git

Exemples :

formalisme de la connaissance

id : 20200625115033
dernière édition :
type : architecture
mots-clés : Bruno Bachimont, Jack Goody, Samuel Goyet

L’écriture et le calcul permettent successivement d’appréhender la connaissance de manière formelle, respectivement selon la raison graphique et la raison computationnelle. Ce sont des « technologies de l’intellect »[^2] dans la mesure où elles permettent de gérer la complexité 🔗, ses représentations. Le formalisme « permet de manipuler des énoncés d’un point de vue formel, en ne considérant plus leur sens mais leur structure »[^5].

Il s’agit de constituer des « structures conceptuelles, conditionnant notre mode de pensée »[^1], des matrices, puis des systèmes automatiques.

Raison graphique

Dans son livre La Raison graphique (1979), Jack Goody évoque trois formes d’écriture (manuscrite ou numérique) pour formaliser la connaissance : la liste, le tableau et la formule.

« En délinéarisant le flux temporel pour le projeter sur une structure spatiale […], l’écriture permet l’émergence de structures de signification qui sont inexprimables par la seule parole »[^3]

« Le texte écrit est par lui-même générateur d’une conscience plus aiguë des structures du langages tant syntaxiques (ou grammaticales) que sémantique (systèmes catégoriels) »[^2] p.10

Bruno Bachimont décrit ainsi ces formes dans son livre Ingénierie des connaissances et des contenus (2007) :

  • liste : elle permet de découper, délinéariser un discours en unités qu’il est possible de prélever pour les classer, catégoriser, hiérarchiser ;
  • tableau : représentation d’un ensemble de rapports systémiques entre des données caractérisées par leur position (topologie) sur deux dimensions : vertical (colonne) et horizontal (ligne) et par rapport aux métadonnées en périphérie. Quand on est face à un tableau, on cherche les trous, les rapports entre les différentes dimensions dont on aurait pas encore trouvé la valeur comme lors d’un produit en croix ;
  • formule : raisonnement écrit dont on n’a pas besoin de comprendre la signification, mais dont on peut saisir le geste par la forme (normée).

L’informatique est la radicalisation de cette dernière forme d’écriture. Il n’y a pas de computationnel, de calcul, sans écriture.

Raison computationnelle

🔗 inscription computationnelle

Bruno Bachimont va reprendre cette typologie comme prisme pour une analyse des structures de la connaissance en informatique. Elle sont basées sur la discrétisation 🔗 et la formalisation de signes destinés au calcul, à la computation. Ainsi, la liste, le tableau et la formules deviennent respectivement[^4] :

  • programme : selon la même idée que la liste, le programme 🔗 est une série d’instructions pouvant être interchangées puis finalement exécutés dans l’ordre prescrit ;
  • réseau 🔗 : une fois les données structurées comme dans un tableau (statique), le réseau propose de redisposer et réévaluer ces informations (dynamique) ;
  • couche : entendue comme niveau d’abstraction, la couche permet de faire abstraction de calculs sous-jacent pour se concentrer sur le résultat formalisé, comme la formule. 🔗

[^1]: Bruno Bachimont, Ingénierie des connaissances et des contenus, 2007 [^2]: Jack Goody, La Raison graphique, 1979 [^3]: Bruno Bachimont, Herméneutique matérielle et Artéfacture : des machines qui pensent aux machines qui donnent à penser ; Critique du formalisme en intelligence artificielle, 1996 [^4]: Bruno Bachimont, Signes formels et computation numérique : entre intuition et formalisme, 2004 [^5]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

formats de documentation logicielle

id : 20211003123941
dernière édition :
type : documentation

Faire varier les formats de la documentation logicielle 🔗 permet à ses utilisateurs-développeurs d’aborder les informations exposées selon plusieurs vues 🔗 en travaillant le formalisme de ces connaissances 🔗.

« Les ingénieurs logiciels comprennent un système en présentant ses caractéristiques sous une forme qui peut être facilement traiter cognitivement. Le choix d’un format de documentation doit donc être basé sur une analyse des exigences de traitement cognitif posées par les différents formats de représentation »[^1] (p.167)

Ainsi, varier les formats de presentation de la documentation permet de faciliter le travail cognitif 🔗 des développeurs.

« Afin d’acquérir les informations nécessaires pour concevoir une meilleure documentation, il sera nécessaire d’identifier les propriétés des différents formats qui améliorent la capacité des d’identifier rapidement et précisément l’information »[^1] (p.172)

Bill Curtis propose neuf formats de documentation[^1] (p.167), faisant varier

  • la symbologie (langage naturel, langage contraint et idéogrammes) 🔗
  • la disposition spatiale (séquentielle, ramification et hiérarchique) 🔗

Ainsi, il serait possible de formuler une algorithme avec un langage naturel, contrôlé ou bien des symboles, suivant la forme et la logique d’une séquence, d’une ramification ou d’une arborescence 🔗 (hiérarchique). On peut exprimer une ramification en langae naturel non pas en imitant sa forme, mais en exprimant sa logique, mettant en avant la circulation des données au travers de plusieurs structures de contrôle 🔗, notamment des conditionnelles. On peut totalement basculer la représentation hierarchique sous un mode diagramme ou bien utiliser des mots-clés issus d’un langage contrôlé et répartis dans l’espace comme ci-dessous.

SET personne     SET access
      |               |
      |               |
      --------|--------
              |
          GET user

Observations

« Le langage naturel s’est avéré moins efficace pour aider la plupart des tâches étudiées qu’un langage contraint »[^1] (p.167)

« pour les problèmes impliquant des compromis entre seulement deux facteurs, davantage d’erreurs de décision étaient commises avec le format prose qu’avec les phrases, le tableau ou l’arbre. Lorsque la décision devenait plus complexe »[^1] (p.168)

[^1]: Bill Curtis, Experimental evaluation of software documentation formats, 1989

formats de fichier numériques

id : 20200618141829
dernière édition :
type : inscription

L’ordinateur dresse un index des formats de fichiers et des outils permettant de les interpréter. Ainsi un certain nombre de formats de fichier dépendent d'un logiciel, voire de sa version. Le contenu d'un fichier peut aussi ne pas correspondre au format annoncé (en général par son extension).

Typologie

  • format propriétaire : les spécifications 🔗 techniques sont détenues par une organisation privé comme pour le .docx de Microsoft ou le .pdf de Adobe. Toutefois, pour ces exemples, les spécifications techniques sont publiées.
    • format opaque : les spécifications 🔗 ne sont pas diffusées comme pour l'ancien format .doc de Microsoft.
  • formats libres ou ouverts : les concepteurs ne revendiquent pas la propriété comme pour les formats .html, .json.

L’extension n'est qu'une information sur le format du fichier : elle peut être modifiée. Par exemple, changer l'extension .docx d'un fichier Word en .zip (archive) permet de se rendre compte que les fichiers .docx sont en fait des répertoires comportant une multitude de fichiers.

Choix

On ne choisit pas un format de fichier par hasard. Ils brident plus ou moins l'affichage et la modification des données qu'ils contiennent, sont plus ou moins interopérables, plus ou moins légers.

🔗 texte brut 🔗 langages de balisage léger

formulaires

id : 20210117100240
dernière édition :
type : inscription

Un formulaire est un document préparé pour recueillir des réponses d’une population ciblée. Il est formalisé comme une série de champs. Chaque champ est une question à laquelle l’usager peut répondre selon les modalités proposées.

L’intérêt du formulaire est de guider l’usager à trouver la réponse, mais aussi à la formuler. Pour une question, une série d’images ou d’autres documents on peut ainsi proposer des réponses prêtes à être approuvées par l’usager, ou bien le laisser s’exprimer plus librement.

Formater la saisie

Ce qui sont des consignes sur le papier peuvent devenir des conditions de saisie sur les supports numériques. Ainsi, on peut limiter les réponses d’un champ quant à leur type (alphabétique, numérique, alphanumérique, fichier), le nombre de caractère. On peut aussi mettre en place des contraintes formelles comme l’obligation de cocher un certain nombre de réponse.

Comme cela on s’assure que les informations récoltées peuvent rentrer dans un système d’information, qu’elles sont formatées pour pouvoir être prises en charge par le système.

framework ou cadriciel

id : 20200701222949
dernière édition :
type : architecture
mots-clés : outil

🔗 dépendances logicielles

Un framework, ou cadritiel (cadre de travail), est une base logicielle venant encadrer le développement d’un projet dont il intègre le code source et pour lequel il va fournir des modèles 🔗, voire prescrire une architecture 🔗, fournir des outils de développement. Les framework peuvent contrôler globalement les imports de bibliothèques 🔗 (voir l’exemple de VueJs ci-après).

Ils présentent plusieurs avantages :

  • accélération du développement ;
  • entraide de la communauté et documentation complète ;
  • sécurité et fiabilité sur une base de fonctionnalités.

Toutefois, il s’agit de projet open source 🔗 et ils peuvent dont être abandonnés. Aussi, les framework n’apportent pas de pluvalue métier : deux équipes qui travaillent avec le même cadriciel n’ont aucun avantage concurrentiel entre elles.

Cas

Le framework Hugo permet de créer des sites statiques. Les fichiers que l’on intègre à l’arborescence d’un répertoire couvert par le framework ont une place très précise, laquelle détermine leur traitement. Par exemple, un fichier de style placé dans le répertoire /assets/css prévaut sur (remplace) son équivalent provenant d’un dans un thème et placé dans le répertoire /themes/theme_name/assets/css. Hugo met à disposition des développeurs la commande hugo serve qui permet d’initialiser le site sur un serveur web local, automatiquement actualisé à chaque modification.

Le CMS Wordpress peut être considérer comme un framework dans le sens où il organise une base de données et met à disposition une série de fonctions pour construire des pages web compatibles avec des thèmes et mises à jour régulières.

VueJs est une framework progressif (progressive framework). C’est à dire qu’il peut être utilisé à différentes échelles dans le projet. À l’échelle d’une bibliothèque 🔗 utilisée sur quelques éléments de quelques pages ou bien un framework, utilisé pour couvrir une grande partie ou la totalité des usages du développeur. Pour être intégrées dans ce second environnement de développement 🔗 particulier, les bibliothèques 🔗 doivent être adaptées à VueJs, avec une version particulière.

Le framwork Laravel cadre des logiciels PHP. Il met à disposition des développeurs de nombreuses classes et fonctions pour rediriger, authentifier l’utilisateur, mettre en place des routes d’accès ou encore sécuriser et faciliter l’écriture des appels à une base de données. Le framwork Express remplit à peu près les mêmes fonctions pour l’environnement NodeJs.

gestionnaire de dépendances

id : 20210221151929
dernière édition :
type : architecture

🔗 dépendances logicielles

Dans l’espace d’un logiciel 🔗 on retrouve de nombreuses bibliothèques 🔗, des frameworks 🔗 ainsi que des outils de développement 🔗. Tous peuvent être installés en une commande grâce aux gestionnaires de dépendances.

Ce sont des logiciels installés sur la machine du développeur. Ils sont connectés à des serveurs de livraison de fichiers. À chaque installation d’un paquet une liste de configuration est complétée et peut être transmise à un autre développeur. C’est le fichier package.json de NodeJs. Il n’aura alors plus qu’à exécuter une commande qui téléchargera tous les paquets nécessaires.

Lors de l’enregistrement d’une dépendance, on prend garde à sa version. Elle elle notée dans la liste de configuration et fait référence. En effet, un changement majeur pour une dépendance peut entraîner le dysfonctionnement général du logiciel dépendant.

Environnement Gestionnaire Base
JavaScript NPM, Yarn https://www.npmjs.com/
PHP Composer https://packagist.org/
Python pip https://pypi.org/
Ruby RubyGems https://rubygems.org/

git flow, programmation agile

id : 20200707101657
dernière édition :
type : architecture
mots-clés : projet

🔗 versionnement Git 🔗 méthode des projets agiles

Il n’est pas possible pour deux développeurs de travailler en même temps sur les mêmes fichiers. Ils doivent déplacer leur travail dans le temps ou l'espace pour pouvoir co-contribuer à un même projet. Les systèmes de gestion de version comme Git permettent de créer des branches et ainsi de réserver un espace à la contribution d’une personne et de reporter l’intégration de ces modifications dans le code source.

Ainsi la formation de l’équipe influe largement sur la modularisation du code 🔗. On divise le code en fichiers et modules pour faciliter le travail des développeurs.

Équipe

Est lead-dev est une personne particulièrement soucieuse de la cohérence du projet, du respect de la présente convention de développement. Iel est capable de comprendre les différents langages et connaît les méthodes de développement. Sans nécessairement installer une hiérarchie, c’est un·e développeur·se qui obtient une responsabilité supplémentaire, celle de la revue de code. Iel ne corrige pas nécessairement le code, mais le relis et le valide ou non.

Git Flow

Le dépôt (repository) contenant le code source est divisé en plusieurs branches (branch) permettant de différencier plusieurs étapes dans le code source. Les branchs permettent de garder un code source bien lisibles

![schema git flow](./images fiches/git flow.png)

  • Master : c’est la branch unique maîtresse, dite de production. Elle ne contient que des produits finis répartis en versions et composés d’un code fonctionnel et abouti. À chaque merge dans le master on considère qu’une nouvelle version indépendante est créée, utilisable. On ne modifie jamais directement le master qui, s’il contient des bugs, est retravaillé dans la branch Develop.
  • Develop : c’est la branch unique de développement regroupant les fonctionnalités dernièrement développées et mises en commun : le tout doit encore y être debuggé par le·a lead-dev. Une fois que toutes les fonctionnalités ont été réunies et qu’elles interagissent sans bug, cette branch est merge dans le master.
  • Feature : c’est une branch de fonctionnalité. Il est possible d’en créer une multitude rigoureusement différenciées par leur nom feature-[nom_fonctionnalité]. On fait bien attention à y développer cette unique fonction tant qu’elle est indépendante (qu’elle se suffit à elle-même). Il est envisageable de fork une branch Feature sous ne nom feature-[nom_fonctionnalité]--[spécification], mais une à la fois et avec précaution. Une fois que cette fonctionnalité est aboutie, vérifiée et débuggée, elle peut être merge dans la branch Develop.

Source : https://fr.lutece.paris.fr/

Pour que les fonctionnalités soient bien indépendantes, il est nécessaire de découper préalablement le projet en travaux à assigner aux développeur·euse·s qui vont travailler dans leurs branch Feature.

Mouvements

Dans la mesure du possible, on ne merge que vers le haut : de Feature à Develop et de Develop à Master*.* L’appel (pull) d’une branch supérieure depuis une branch inférieure peut en effet causer des conflits. La supérieure, espace de merge et de débogage, peut être incompatible avec l’inférieure, non-débugué ou même compatible avec les merges d’autres Feature. Suite à un pull dans une Feature, elle devra être débuggée pour poursuivre son développement. Si ces corrections ne sont pas compatibles avec celles auparavant effectuées dans la branch supérieure, on va droit dans le mur. Même lorsque le pull ne cause pas immédiatement de bug, c’est lors du merge final de la Feature que peuvent apparaitre des anomalies complexes ; le code source est alors bon à jeter et il faut rollback. En prévention de cela, il ne faut pas supprimer les Feature qui n’ont pas été merge dans le Master.

Pour échanger autour du code qui a été commit, on profite des outils Git. Les développeur·euse·s doivent régulièrement envoyer leur travail sur le repository et annoncer leur avancement pour recueillir les remarques des collaborateurs et pouvoir profiter du rollback, utile en cas d’embourbement. Ainsi, un·e développeur·se qui pense avoir achevé son travail émet une demande de fusion (merge-request) pour la branch supérieure. Le·a lead-dev confirme ou non cette demande.

Il est important de ne pas accumuler les merges de Feature par intermittence, mais de les exécuter tous ensemble. Les forks de Develop donnant les branchs Feature doivent pouvoir partir d’une base fonctionnelle, débuggée. Sans cela il faudra re-alimenter (pull) les branches Feature avec la version corrigée et cela peut causer des conflits immédiatement ou par la suite. Le conflit, c’est l’échec du processus de versionning. Pour l’éviter, il faut débuter une nouvelle séquence de développement par un merge de toutes les branchs Feature au sein de Develop. Là on débugue et seulement ensuite on pourra fork pour développer les nouvelles fonctionnalités sur des bases saines. En attendant ce merge de toutes les branchs Feature au sein de Develop, les développeur·euse·s continuent de fork la même base de code source depuis Develop en laissant en attente les Feature abouties.

grammatisation

id : 20200905210104
dernière édition :
type : inscription
mots-clés : Bruno Bachimont

C’est un concept de Bruno Bachimont. Il s’agit d’un « système d’expression qui donne lieu à une manipulation et qui de ce fait reconfigure nos possibilités même d’expression »[^1].

Il prend l’exemple de l’écriture comme grammatisation de la parole dans la mesure où l’écriture permet de « codifier dans un système de manipulation »[^1], comme l’alphabet, « permet de reconfigurer ce que l’on a à dire », le discours.

De la même manière, numériser une photographie argentique c’est faire la grammatisation du cliché : il pourra être manipulé sur des logiciels car transformé en code machine pouvant être calculé. On a ainsi augmenté nos possibilités d’expression.

« On réduit une expression à son pur potentiel calculatoire »[^1]

🔗 inscription computationnelle

[^1]: Bruno Bachimont, Rhétorique de l’intelligibilité, vers des humanités du numérique, 2020

graphe

id : 20200625172823
dernière édition :
type : architecture

Le graphe est un modèle mathématique, une structure composée d’objets (sommets) mis en relation. Un graphe, s’il est toujours logique, n’est pas nécessairement graphique ; ce peut être une représentation abstraite 🔗 de relations entre des entités de nature diverse.

Il peut être représenté sous la forme d’un diagramme 🔗, d’un nuage de nœuds reliés par des liens. Ils ont parfois « orientés », c’est à dire que les liens sont des flèches donnant une sens de lecture et une hiérarchie entre les nœuds.

🔗 visualisation

On peut évaluer différents type de liaisons caractérisées par

  • la centralité ;
  • la connexité : plus petit nombre de canaux dont la fermeture entraîne l’isolement.

![typologie des graph](./images fiches/typologies graph.png)

  1. homogène : nœuds et liens reproduisent un schéma régulier, ici matriciel
  2. hiérarchique : les sommets s'arrangent en couches hiérarchisées et pyramidales
  3. cycliques
  4. polaire : tous les sommets sont rattachés à un seul sommet
  5. quelconque

🔗 formalisme de la connaissance

On représente souvent les graphes avec différents pôles : des graphes polaires et quelconque sont répartis dans un espace par des liens dits « faibles »

![typologie des graph](./images fiches/graph decentralise pole.png)

Les graphiques ne sont pas des modèles ; ils sont des versions simplifiées d'une structure théorique à la manière des cartes.

« La théorie des graphes a connu des prolongements, notamment la théorie des hypergraphes, qui autorise des relations multiples sur un même plan ou au sein de couches hiérarchisées »[^1]

Formes

  • arborescence 🔗 : un élément est nécessairement subordonné à un autre élément, sans inversion possible ;
  • rhizome : « tout élément peut influencer un élément de sa structure, peu importe sa position ou le moment, et ce de manière réciproque » (Wikipédia) ;
  • labyrinthe : espace avec une entrée et une sortie ;
  • nuage : l’espace est mouvant, régis par le calcul statistique.

[^1]: Serge Diebolt, Le petit lexique des termes de la complexité

hacker

id : 20210323194802
dernière édition :
type : undefined
mots-clés : politique

Un hacker est un débrouillard, une personne qui maîtrise l’outil informatique et s’emparent plus largement des questions d’éthique des réseaux (néthique, le partage des connaissances), de perfectionnisme du travail et qui refuse de l’autorité (du marché)[^1]. On le confond souvent avec son cousin cracker, destructeur de système informatique.

Il est opposé au lurker, l’utilisateur passif, au luser utilisateur irritant par sa non expérience de l’informatique. Ils sont critiques de l’arrivée massive des usagers d’Internet depuis le Septembre éternel de 1993, quand aux universitaires (formés entre septembre et octobre) s’est ajoutée la population inexpérimentée (impossible à former).

Communauté

Les hackers sont fondamentalement communautaires. Ils fabriquent des outils informatiques pour le bien communs. Parallèlement, ils sont soucieux de prouver (netiquette, reconnaissance en ligne) leur mérite par leurs compétences personnelles, leurs réalisations et revendiquent leur paternité sur leur réalisations, leur code.

Cela se mue chez en une volonté d’obscure. Celle de se réfugier dans (ou de concevoir) des interfaces inutilisables par le plus grand nombre (non usage ou non expérience). Elle leur donne un sentiment de satisfaction et de privilège dont ils jouissent en élite[^2]. Même dans cette élite, il doivent se distinguer parmi les nombreux challengers.

Culture du mot

Par le code, la ligne de commande, les hackers entretiennent la culture du mot[^3]. Ils manipulent en continu le clavier (sans être interrompus par la souris) et le vocabulaire, la syntaxe ; la composition d’un langage dans un système pour entretenir une « expression puissante et compacte »[^3].

« Les utilitaires du système UNIX sont une sorte de jeu de construction Lego pour les fabricants de mots. Des tuyaux et des filtres relient un utilitaire au suivant, le texte circule de manière invisible entre eux. Travailler avec un shell, des dérivés d'awk/lex, ou l'ensemble des utilitaires est littéralement une danse des mots. »[^3]

[^1]: Pekka Himanen, L’éthique hacker, 2001 [^2]: David M. Nichols, The Usability of Open Source Software, 2002 [^3]: Miller Freeman, The Elements Of Style: UNIX As Literature, 1998

headless CMS

id : 20210312173555
dernière édition :
type : processus
mots-clés : technique

Par rapport aux CMS (Content Managment System) traditionnels (Wordpress, Joomla…) le headless CMS (système de gestion de contenus sans interface) n’a par d’interface front end. On ne garde que les interfaces suivantes :

  • la gestion des données, via une interface back end de modélisation et d’enregistrement ;
  • le système de requêtes via une API 🔗.

L’avantage de ce système est sa souplesse, sa robustesse grâce aux API. Il permet de réaliser des projet ad hoc, destiné à un usage particulier.

Souplesse

Greffés sur une seule base de données, les headless CMS peuvent recevoir et distribuer de l’information à une multitude d’interfaces et terminaux (site web, applications mobiles…) tout en centralisant les données qu’ils renvoient. L’API peut ainsi capter et renvoyer une variété de requêtes.

Ils permettent aussi à une variété d’usagers de modifier les données du site avec une gestion stricte des permissions d’utilisateurs authentifiés.

Robustesse

Séparer la base de données de son affichage permet de limiter les réactions en chaînes en cas de problèmes techniques ou simplement de maintenance 🔗 des interfaces connectées. L’accès est également plus difficile pour les intrus, les intéractions étanat limitées à des requêtes à une API limitée.

histoire de OpenSSL

id : 20200705101927
dernière édition :
type : undefined

Dans son livre Sur quoi reposent nos infrastructures numériques ? (2017), Nadia Eghbal évoque le groupe de développeurs réunis en 1998 qui a construit OpenSSL. Un développeur à temps plein et une poignée de développeurs bénévoles maintiennent depuis un logiciel qui sécurise une très grande partie des infrastructures du web, même les GAFAM, Netflix, notamment pour les transactions bancaires.

Cette équipe a manqué de moyens durant toute son existence, et aujoud’hui encore elle compte sur un bien faible effectif et peu de dons par rapport au service qu’elle rend à l’humanité.

« Il y avait juste de quoi payer le salaire d’un développeur, Stephen Henson. Cela signifie que les deux tiers du Web reposaient sur un logiciel de chiffrement maintenu par un seul employé à temps plein »[^1]

Une faille majeur, Heartbleed, a permise « à n’importe quel pirate suffisamment doué de détourner des informations sécurisées en transit vers des serveurs vulnérables »[^1]

« Ce qui est mystérieux, ce n’est pas qu’une poignée de bénévoles surchargés de travail ait raté ce bug, mais plutôt qu’il n’y ait pas eu davantage de bugs de ce genre »

[^1]: Nadia Eghbal, Sur quoi reposent nos infrastructures numériques ?, 2017

hyper

id : 20210114195936
dernière édition :
type : processus

hyper- est un préfixe largement utilisé dans le domaine du numérique avec hypertexte, hypermédia… On lui trouve un sens mathématique, celui d’extension, de généralisation[^1]. Ainsi, hyper- est relatif à la structure et non à la taille[^1].

« Sens spatial ou quasi-spatial de ‹ au-dessus ›, ‹ au-délà › »[^2]

Cette notion d’extension est bien souvent une notion de mise en réseau, de liaison entre des objets d’un espace donné.

🔗 hypertexte

L’hyper- structure n’est pas perceptible directement par nos sens. Il faut une machine pour pouvoir l’apprécier.

[^1]: Ted Nelson, The Home Computer Revolution, 1977 [^2]: Trésor de la langue française

HyperCard

id : 20200622183005
dernière édition :
type : architecture
mots-clés : histoire

HyperCard est un logiciel développé par Apple en 1987 pour Mac OS versions 9 (compatible avec les versions antérieures). Il inclut une interface graphique et un langage de programmation, HyperTalk (langage de programmation à la syntaxe très proche de la lange anglaise rendant la programmation accessible) permettant de réaliser des applications.

put the value of card field "typehere" into theValue

Le logiciel permet de créer des bases de données (piles de cartes si on utilise le jargon du logiciel), par exemple, un carnet d'adresses : l'utilisateur créer les champs (prénom, nom, adresse, téléphone… ) et n'a qu'à instancier les cartes ainsi formatées.

🔗 instance informatique 🔗 fiche comme modèle de données 🔗 base de données

Les piles se présentaient sous la forme d'un diaporama et deux flèches permettaient de faire défiler les cartes. Le logiciel proposait nativement une série de pile pré-conçues et supportait textes, images et sons. Il était également possible d'ajouter des boutons, de leur associé des actions comme jouer un son.

Le logiciel inclut une fonction de recherche dans les données et il était possible au clic de passer d'une carte à une autre. C'est l'un des premiers procédé hypertexte assimilable à un système de fiche.

🔗 hypertexte

« It's kind of the freedom to organize the information, according to are things or associate with each other, not just according to the next in the list »[^1]

[^1]: Bill Atkinson, vidéo Hypercard

hypermédia

id : 20200625163043
dernière édition :
type : inscription

🔗 hyper 🔗 hypertexte

Sont hypermédias les supports combinant plusieurs type de média comme la son, l’image ou la vidéo. Ils profitent de la technologie hypertexte qui permet « d’évoquer simultanément les questions liées à la nature du support ou du média et celles liées au type d’organisation qu’il met en œuvre »[^1]

« L'autre idée [avec l'hypertexte], qui est indépendante et largement une question de technologie et de temps, concerne les documents multimédias qui incluent des graphiques, de la parole et de la vidéo. Je ne discuterai pas davantage de ce dernier aspect ici, bien que j'emploierai le mot ‹ Hypermédia › pour indiquer que l'on n'est pas lié au texte. »[^2]

[^1]: Olivier Ertzscheid, Les enjeux cognitifs et stylistiques de l’organisation hypertextuelle, 2002 [^2]: Tim Berners-Lee, The original proposal of the WWW, HTMLized, 1990

hypertexte

id : 20200622164608
dernière édition :
type : architecture

🔗 hyper

Thed Nelson, considéré comme l’inventeur du terme, donne la définition suivante de l’hypertexte : « une écriture-lecture non-linéaire donnant à l’utilisateur une liberté de mouvement  » soit un système basé sur l’interaction (« hypertextualité »[^2]) dans l’espace d’une base documentaire.

L’hypertexte désigne tantôt un principe d’organisation « réticulaire » (en réseau 🔗) de l’information, tantôt une série de techniques et d’outils.

« l’hypertexte une notion et non une technologie, un mode de lecture-écriture qui s’est incarné à travers des techniques très différentes et qui ne saurait être réduit à une seule d’entre elles »[^1]

En tant que notion, la logique de l’hypertexte est intégrée tant dans les documents papiers que les documents numériques, qu’ils soient paginés ou sous la forme de volumen (rouleau). En tant que technologie, l’hypertexte est notamment à l’origine des techniques d’édition numériques 🔗.

Histoire

On retrouve les origines de l’hypertexte dans les années 1930. Son inspiration vient des techniques documentaires et informatiques (qu’il continue d’enrichir) formées par les théories utopistes du savoir universel de Paul Otlet, Vannevar Bush. Ces deux inventeurs comptent largement sur la participation de l’ingénieur Emanuel Golberg qui a fournit les supports d’enregistrement (micro-cartes). Ils placent la fiche comme modèle de données 🔗 pour former des bases documentaires.

L’hypertexte a été conceptualisé dans les années 1930, notamment par Paul Otlet dans son Traité de documentation et Vannevar Bush avec sa théorie du Memex 🔗, son article As we may think. Ils ont « nourri » ce concept avant qu’il n’arrive en informatique, dans les années 80, notamment grâce au logiciel HyperCard 🔗 de Apple.

Comme technique

La technique hypertexte s’explique explicitement avec le lien hypertexte. Il s’agit d’une chaine de caractère à laquelle on a attaché une cible. Dans le contexte d’une page web, on formalise les liens hypertexte de la manière suivante, ou à la manière des wikilinks 🔗. La chaîne de caractère Site de Guillaue Brioudes est l’ancre du lien hypertexte ciblant l’adresse https://myllaume.fr/. L’ancre suggère la cible. L’intéraction du clic permet à l’utilisateur de suivre ce lien hypertexte à son appréciation.

<a href="https://myllaume.fr/">Site de Guillaue Brioudes</a>

L’hypertexte est aussi une technique bien plus discrète. C’est une entrée dans un index tel que la table des matières dans un livre. La paire que forment le titre de section et le numéro de page où il se trouve est une lien hypertexte. Ainsi, le principe de l’hypertexte précède de loin l’invention du terme. Ce qui fait la modernité de l’hypertexte, ce sont les notions qu’on lui attache.

Comme notion

L’hypertexte se conçois au sein d’une base documentaire et non pas au sein de, à partir d’un unique document. Le système hypertexte se déploie dans une base documentaire dans la mesure où chaque élément (à la fois cible et source) est identifié (identifiants uniques) dans les limites de la base pour former un espace de nom 🔗. C’est à cette condition que les liens sont fonctionnels et pérennes.

Le concepteur de cette base documentaire cherche à offrir la sérendipité à ses lecteurs (appelés « utilisateurs » suivant leur intéraction avec le texte, devenu un outil intellectuel de recherche active). Ainsi on permet aux personnes de découvrir, par hasard ou sagacité, une information qu’ils étaient venu cherché intentionnelement ou non. Elles vont se rendre de document en document en suivant les liens qui les intéressent.

Pour que cela soit possible, il faut soigner les ancres de nos liens hypertextes et ainsi suggérer à l’utilisateur ce qu’il va pouvoir trouver une fois rendu sur la cible. C’est particulièrement pertinent car l’esprit humain fonctionne par association d’idée. Un lecteur pourrait suivre un chemin entre les pages suivantes.

  1. « Programmation »,
  2. « Programmation orientée objet »,
  3. « Prototypage »,
  4. « JavaScript ».

Le lecteur aurait pu se rendre à l’étape 2 sur la page « Programmation fonctionnelle » et d’ici découvrir d’autres informations.

Sens

On ne peut saisir une idée sans saisir son champ. Lequel ne s’étend pas de manière linéaire, d’où le besoin des techniques hypertexte pour le saisir.

« toute l’acquisition du langage consiste à associer des mots et des objets, à désigner des abstractions par des concepts […] tout effort intellectuel, du plus simple au plus complexe, passe par l’activation d’un réseau d’associations qui permettent à la pensée de se mettre en place et de saisir les objets et/ou les concepts qu’elle vise à appréhender »[^2]

L’hypertexte est « une structure indéfiniment récursive du sens »[^2] : il projette son sens propre, donne du sens à sa source, et recommence. L’hypertexte ne modifie pas le structure de son document (elle-même porteuse de sens), mais dispose des chemins de traverses.

« L’hypertexte est ce qui reste de l’édifice du sens, une fois la pierre du texte ôtée »[^2]

Pour reprendre l’exemple précédant, les pages « Programmation » et « JavaScript » sont liées notamment par l’intermédiaires de « Programmation orientée objet » et « Prototypage », mais aussi par le sens : JavaScript permet de faire de la programmation, de la programmation orientée objet et pour cela fonctionne par prototypage. De même que le prototypage est un artefact de la programmation orientée objet et peut être implémenté notamment en JavaScript. Enfin, la page « JavaScript » pourra également diriger l’utilisateur vers « Programmation fonctionnelle ».

La page « JavaScript » est la quatrième étape de lecture d’une personne, mais potentiellement la première étape de lecture d’une autre personne. S’il peut y avoir une hierarchie entre les pages (et en leur sein), il n’y a pas de hierarchie sur les liens entre les pages. Une base hypertexte est une organisation rhizomatique dans la mesure où tout document peut réciproquement en influencer une autre (par le sens), sans soucis hiérarchique.

Graphe

🔗 formalisme de la connaissance

Si chaque document est un sommet mis en relation avec d’autres (d’après la cible de leurs liens hypertextes respectifs), alors les documents forment un graphe 🔗. Il est possible de le représenter et ainsi de visualiser 🔗 les liens qu’entretiennent les pages entres elles. Pour reprendre le même exemple, on pourrait visuellement démontrer le lien entre les notions entre « Programmation », « Programmation orientée objet », « Prototypage » et « JavaScript », ainsi que tous leurs autres liens, « Programmation fonctionnelle » étant lié tant à « Programmation » que « JavaScript ».

Il est alors particulièrement intressant d’observer des centralités, des sommets (pages) auxquels sont attachés de nombreux liens et autour desquels les algorithmes de spatialisation disposeraient de nombreux autres sommets. On peut dès lors identifier les pages correspondantes comme clés dans le compréhesion du sens de la base documentaire.

La cardinalité d’un système hypertexte est « la possibilité d’établir des liens hypertextuels non plus mono-directionnels mais multi-directionnels (depuis un ou plusieurs documents, vers un ou plusieurs autres), leurs ancres faisant alors office de pivot »[^2]. On décentralise la connaissance : « L’hypertexte est un système infiniment dé-centrable et re-centrable dont le point de focalisation provisoire dépend du lecteur »[^3]. L’hypertexte dépasse les trois dimensions, le domaine de ce qui peut être perçu, d’où le préfixe hyper- 🔗. L’hypertexte est la géométrie non euclidienne du texte.

[^1]: Alexandre Serres, Hypertexte : une histoire à revisiter, 2015. [^2]: Olivier Ertzscheid, Les enjeux cognitifs et stylistiques de l’organisation hypertextuelle: le Lieu, Le Lien, Le Livre, 2002 [^3]: George Landow, Hypertext, 1991

implémentation

id : 20210813142150
dernière édition :
type : programmation

L’implémentation est un anglicisme depuis le verbe implement. Il signifie comme verbe « mettre en œuvre » et comme nom « l’outillage ». De manière très élégante, il permet de parler à la fois des spécifications 🔗 (qui vont être intégrées à l’ouvrage) et des outils (moyens) qui vont être mobilisés pour cela.

L’implémentation est la reformulation d’une spécification 🔗 avec un langage informatique.

L’implémentation est autre chose que l’implantation, l’installation d’un programme ou d’un logiciel dans un espace informatique plus grand.

index de l’API

id : 20210524081927
dernière édition :
type : documentation

L’index de l’API 🔗 recense exhaustivement certaines inscriptions de l’espace de nom 🔗. Parmi celles qui intéressent le plus les développeurs, on retrouve les fonctions 🔗, les différentes définitions d’une variable 🔗[^2] (p.4). Grâce à la documentation du code 🔗, chaque inscription peut être expliquée, permettant ainsi aux développeurs de retrouver rapidement son usage.

Un index étant une liste ordonnée avec renvois. Ainsi, l’index de l’API renvoie son lecteur vers le fichier de code source correspondant à chaque inscription. Le code source est découpé en lignes (de code), lesquelles sont les ancres de la définition d’un inscription donnée.

L’un des avantages d’une telle documentation est qu’elle est mise à jour avec le code source et ne nécessite pas que le développeurs sortent de leurs fichiers de code pour la compléter. Ainsi, seul le point de vue du développeur (complété lors de la revue de code 🔗) est présenté. Toutefois, ce type de documentation ne permet pas d’avoir une vue d’ensemble du logiciel, de comprendre son architecture 🔗[^3] (p.3).

Génération

Ces index peuvent être générés grâce à des logiciels comme JSDoc 🔗, phpDocumentor, JavaDoc[^1] qui vont analyser les commentaires 🔗 inscrits et leur cible dans le code source pour générer un site web statique 🔗 avec une navigation, une mise en page permettant de retrouver ces entités et leurs caractéristiques.

[^1]: E. Berlung, Writing for adaptable documentation, 2000 [^2]: Susan Elliott Sim, Browsing and searching software architectures, 1999 [^3]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

ingenierie logicielle

id : 20211011175724
dernière édition :
type : processus

La conception de modèles 🔗 est un des principes fondamentaux de l’ingénierie, comme processus de travail. « Un concept de base de l’ingénierie est de traiter les problèmes d’une manière répétable et cohérente »[^1] (p.33). C’est un processus créatif.

On attend que l’usine ainsi mise en place par l’ingénieur contrôle tout du long la qualité du produit. Dans le cas d’un logiciel, il n’y a pas de moyens de contrôle quantitatifs permettant d’évaluer le travail[^1] (p.33). On essaie donc de mettre en place des supports de coopération (synchronisation) entre les développeurs 🔗 pour aboutir à un travail de qualité, comme la convention de développement 🔗.

Pour faire ce travail, l’ingénieur dispose de modèles de conception existants qu’il adapte à l’ouvrage. Il faut rappeler que la conception de modèles 🔗 n’est pas l’objectif des projets de développement logiciels et que cet investissement doit aider à la production. « Il importe peu que les modèles soient incomplets, dessinés avec une syntaxe incorrecte et ne ressemblent pas au monde réel s’ils communiquent suffisamment aux destinataires »[^1] (p.34). C’est un travail purement pragmatique ; on cherche simplement à faire fonctionner l’usine.

[^1]: Alistair Cockburn, Agile Software Development, 2002

inscription computationnelle

id : 20210116135423
dernière édition :
type : inscription
mots-clés : REVUE

🔗 computationnel 🔗 signe formel

Dans ce sens, le code qui est transmis à la machine porte essentiellement sur ses opérations. Il n’est lui même qu’une abstraction d’un système basé sur la combinaison du binaire, via de portes logiques.

🔗 matérialité d’un programme

« il est possible de comprendre la machine computationnelle comme une machine à écrire […] parce qu’elle permet aux humains d’écrire, mais parce que son fonctionnement repose sur un certain type d’écriture […] qui ne répond pas aux mêmes impératifs que ceux des humains »[^1]

L’écriture des machines « est unidimensionnelle et elle repose des signes monosémiques : la machine scanne un ensemble fini de signes sur un support »[^1].

« une machine computationnelle ‹ écrit › au sens où elle inscrit des symboles univoques sur un espace discrétisé et monodimensionnel »[^2] (p.461)

D’après Alan Turing[^3], une machine n’écrit pas, ne lit pas ; elle scanne (to scan), elle inscrit (to write down) et elle « manipule des symboles »[^2] (p.140). Elle n’interprète pas, n’a pas de mémoire ; elle suit en permanence le cours d’opérations pour effectuer des changements d’état sur ses supports (circuits, disques…).

🔗 matérialité d’un programme

« les signes ne font pas l’objet d’une interprétation contextuelle, mais ne font que renvoyer à une signification précodée qui va déclencher un mouvement de la machine »[^2] (p.140)

L’« écriture-calcul »[^2] de la machine est « auto-reproductible »[^2] (p.140), « Ce qui se calcule est ce qui peut s’écrire automatiquement »[^2] (p.145), dans un système, avec une configuration 🔗 et des valeurs, tant que tous ces éléments sont déterminés à l’avance[^3]. Ainsi, le calcul par la machine est discret 🔗 (suite d’opérations élémentaires et discontinues, des fonctions 🔗), sans quoi il ne peut être combinatoire.

« l’informatique en tant que science est fondée sur une certaine conception automatisée et machinique de l’écriture »[^2] (p.78)

[^1]: Cléo Collomb, Faire compter les machines, 2017 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^3]: Alan Turing, On Computable Numbers, with an Application to the Entscheidungsproblem, 1937

inscription du code

id : 20200530195417
dernière édition :
type : inscription
mots-clés : Samuel Goyet

En programmation, on utilise en général une typographie à châsse fixe (monospace), où la largeur du glyphe (dessin du caractère) est toujours la même, quel qu’il soit. La plus connue de ces typographies est Courrier.

Morphologie typographique

Le fait que les caractères soient dans un espace carré permet d’envisager un alignement vertical en plus de l’alignement horizontal de la ligne. C’est particulièrement important lorsqu’il s’agit d’aligner des corps de texte signifiant par leur contenu, mais aussi par leur forme. Avec un important jeu de glyphes, ces caractères permettent de dessiner des formes à l’écran.

« la linéarité graphique est double, autant vertical qu’horizontale »[^1], (p.11)

Selon leur syntaxe 🔗, les langages de programmation n’ont pas la même morphologie typographique.

  • Les retours à la lignes plus ou moins récurrents. Le XML et ses dérivés sont des fichiers denses formés par de longues ligne de code. Le CSS ou le YAML sont au contraire verticaux.
  • Certains caractères comme {, ] ou ( tendent à dessiner les structures de contrôle 🔗 dont la saisie est rythmée par les différents opérateurs. Ce sont souvent des couples de caractères comme => ou &&.
  • L’indentation du code (avec espaces ou tabulations) facilite sa lecture en suggérant une hiérarchie entre les inscriptions. Elle permet aussi d’aligner les informations semblables.
$courte      = 1
$longueeeeee = 2
$lit         = 3

« Lire du code et des données n’a rien à voir avec la lecture d'un livre. Nous commençons rarement par le début, lisant une ligne à la fois jusqu'à ce que nous atteignions la fin. Au lieu de cela, nous sautons autour, en balayant de nombreuses lignes à la fois. Nous devons rapidement donner un sens à ce que nous regardons, et la typographie peut nous aider à voir les structures complexes qui existent dans nos sources simples, en texte brut »[^3]

La forme du code dépend beaucoup de la syntaxe utilisée qui peut varier d’un langage de programmation à un autre, mais aussi en fonction du paradigme de programmation 🔗 utilisé. En programmation orientée objet 🔗, au sein des classes, les imbrications sont particulièrement complexes.

« Nous montrons notamment que la mise en page, à travers un traitement de texte adapté, permet d’annuler temporairement l’efficacité machinique du code pour, paradoxalement, mieux la préparer : l’organisation spatiale du code permet de repérer clairement les étapes logiques, les bugs, etc. L’analyse de l’indentation du code permet quant à elle de montrer comment l’organisation de l’espace a une fonction de spatialisation du calcul. Cette organisation est donc une façon de rendre lisible pour les humains des opérations qui ont lieu à des échelles qui ne nous sont pas accessibles »[^2] (p.874)

D’après la théorie de l’énonciation éditoriale 🔗, l’espace donné au calcul donne non seulement à lire le programme, mais permet aussi de prescrire ses processus. On lit notamment l’encapsulation 🔗 par l’indentation. Aussi, certains langages ne peut être exécutés s’ils ne sont pas correctement mis en forme (comme le Python).

Les typographies à largeur variable ont en revanche l’avantage de mettre en évidence les erreurs dans un bloc de ligne sensé être identiques. La moindre différence peut causer un léger dé-alignement permettant de réparer l’erreur[^3].

Forme des mots-clés

Les logiciels de traitement de texte intègrent pour la plupart des fonctionnalités de stylisation syntaxique 🔗 facilitant la lecture de certains mots-clés comme this, return, les booléens ou bien d’autres mots pris dans un contexte. Ci-dessous, functionName pourra être coloré tant qu’il est entre le mot-clé function et le couple {}.

function functionName(int) {
	if (int !== 10) {
		return false;
	}

    return 10;
}

Les ligatures accentuent cela. Ainsi des opérateurs comme => sont changés par la police Fira Code en une flèche doublée complète. L’opérateur === est transformé en un signe « égal » à trois barres horizontales. Une barre oblique vient s’ajouter pour l’opérateur !==.

Le code n’est pas écrit pour être lu, mais être interprété. C’est pourquoi je préfère parler d’inscription du texte comme code plutôt que d’écriture. Cette interprétation est le geste d’un humain ou d’une machine, tous deux à la recherche d’une logique sémantique, une inscription systémique d’artefacts 🔗 définis en arborescence.

[^1]: Jack Goody, La Raison graphique, 1979 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^3]: David Jonathan Ross, Drawing for Code

instance de mise en page

id : 20200707112034
dernière édition :
type : architecture

🔗 instance informatique

Avec les logiciels comme Pandoc il est possible transpiler (convertir du code d’un langage à un autre) un fichier plein texte balisé en Mardown ou en HTML en un fichier à la structure plus complexe comme l’ODT ou le PDF.

🔗 transpiler ou compiler du code

Ainsi rédiger en plein texte permet non seulement pour un temps de se concentrer sur le fond plutôt que sur la forme du document, mais aussi à terme de contrôler sa mise en page. Avec des logiciels comme LaTeX ou PageJs on ne reproduit plus une mise en page, mais on l’instancie : les templates produits pour ces logiciels deviennent des class et permettent ainsi de mettre en page à la chaîne plutôt que de recopier une charte.

instance informatique

id : 20200707113753
dernière édition :
type : architecture

Une instance est la reproduction d’un objet. Lequel hérite comme toutes les autres instances de la même classe (ou d’un objet, dans une logique de prototypage) des mêmes attributs et méthodes . C’est la reproduction d’un modèle 🔗.

Les codelets JavaScript et PHP ci-dessous font exactement la même chose :

  1. Déclaration d’un prototype (JavaScript) ou d’une classe (PHP)
  2. Déclaration des attributs prenom, nom, age et genre
  3. Déclaration d’une méthode parler
  4. Instance du prototype (JavaScript) ou de la classe (PHP) en un objet guillaume
  5. Construction de l’objet par l’affectation des valeurs suivantes, respectivement assignées aux attributs précédemment déclarés : Guillaume, Brioudes, 21 et h
  6. Affectation de la valeur Hello world! à la méthode parler et lecture immédiate
function Personne(prenom, nom, age, genre) {
	this.prenom = prenom;
    this.nom = nom;
    this.age = age;
    this.genre = genre;
};
Personne.prototype.parler = function (paroles) {
    console.log(this.prenom + ' ' + this.nom + ' dit ' + paroles);
}

var guillaume = new Personne('Guillaume', 'Brioudes', 21, 'h');

var discours = guillaume.parler('Hello world!');
class Personne {
    private $prenom;
    private $nom;
    private $age;
    private $genre;
    
    function __construct() {
        // ...
    }
    
    public function parler($paroles) {
        echo $this->prenom . ' ' . $this->nom . ' dit ' . $paroles
    }
}

$guillaume = new Personne('Guillaume', 'Brioudes', 21, 'h');

$discours = $guillaume->parler('Hello world!');

interface

id : 20200708132301
dernière édition :
type : inscription
mots-clés : Arthur Perret, REVUE

🔗 responsive

Une interface est « un tiers médiateur organisant des modalités d’interaction »[^1] avec un objet technique. Elle peut aussi en limiter l’usage et l’effort de l’utilisateur qui s’appauvrit dans son expérience de la machine.

« Prenons le voyant lumineux: certes, il possède un sens fonctionnel primaire et univoque, indiquer l’existence d’une tension ou d’un courant ; mais en plus, il est la balise de l’enceinte technophanique, le symbole de l’existence d’un fonctionnement, il indique une présence et une actualité »[^2]

« Or, la généralisation de ces interfaces graphiques représente une régression, un appauvrissement sémantique dans notre relation avec la machine »[^3]

🔗 rapport aux objets techniques

GUI : Graphical User Interface.

Échanges

Quand on parle d’interface, on pense souvent aux interfaces d’utilisation, mais il existe également les interfaces de programmation 🔗, de développement.

On distingue généralement trois couches pour un logiciel (voir ci-dessous). Le développeur se situe sur la deuxième, faisant communiquer les deux extrêmes :

  1. Niveau matériel 🔗 et logiciel fondamental ;
  2. Gestion des « informations persistantes et du contrôle d’activités »[^5] (p.19) ;
  3. interface utilisateur.

Les interfaces utilisateur et développeur font respectivement face à deux problématiques : le « fossé de l’évaluation » et le « fossé d’exécution ».

Le premier se situe entre les intentions, les capacités de l’utilisateur et les représentations effectives de l’interface.

« L’écart est faible lorsque le système fournit des informations sur son état sous une forme facile à obtenir, facile à interpréter et correspondant à l’idée que l’on se fait du système »[^4]

Le second se situe entre les intentions, capacités du développeur et ce que le système lui permet de faire, la mesure dans laquelle il le soutient dans son travail.

[^1]: Arthur Perret, Matière à pensées : outils d’édition et médiation de la créativité, 2018 [^2]: Gilbert Simondon, Sur la technique, 2014 [^3]: Julien Dehut, En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation, 2018 [^4]: Donald Norman, The Psychology of Everyday Things, 1988 [^5]: Sahar Jarwah, Un modèle générique pour la gestion des informations complexes et dynamiques, 1992

interface de module

id : 20210903085646
dernière édition :
type : architecture

L’interface 🔗 d’un module 🔗 porte sur ses limites. Elles permettent à la fois de le relier et de le distinguer des autres module. En programmation, on gère les interfaces entre les fonctions et le classes grâce à l’encapsulation 🔗.

L’interface est conçue selon un modèle 🔗 permettant d’uniformiser les procédures d’accès aux données contenues dans le module.

interfaces d’écriture

id : 20200815162225
dernière édition :
type : inscription

🔗 interface

On reconnaît trois modes de présentation du texte pour les logiciels d'écriture numérique. Le schéma d’iceberg exprime ci-dessous l’enfoncement progressif de l’utilisateur dans la réel essence de son texte

![schema iceberg architecture sémantique](./images fiches/schema iceberg contenu semantique.svg)

WYSIWYG

What You See Is What You Get : point de vue graphique (formel) sur la saisie pour une lecture/écriture destinée à l'impression : la mise en forme est identique de l’interface à l’impression (papier ou numérique).

« L’idée sous-tendue par le WISIWIG […] est d’obtenir sur une page papier l’exacte reproduction de ce qui est représenté à l’écran ; ce qui semble rétrospectivement une condition sine qua non de leur utilisation puisque la finalité des traitements de texte demeure l’impression »[^2]

🔗 problème des logiciels de traitement de texte

Logiciels exemple :

  • Word, Writer, Pages et autre logiciel de traitement de texte
  • TinyMCE, CKEditor
  • Dreamweaver

WYSIWYM

What You See Is What You Mean : point de vue sémantique : on se focalise sur le sens et/par la structure du contenu plutôt que le rendu graphique, l’affichage.

« Cependant, la possibilité d’affichage existe et elle crée une décorrélation intéressante. Ce n’est pas nécessairement une séparation entre fond et forme, puisqu’un même fichier HTML ou LaTeX peut contenir à la fois des informations de nature sémantique et stylistique. »[^1]

🔗 corps de texte balisé, sémantisé, interactif

Logiciels exemple : Zettlr, Obsidian

WYSIWYC

What You See Is What You Code : vue directe sur le code source avec possibilité de l’éditer.

🔗 inscription du code

Logiciels exemple : VS Code, BBEedit, Notepad++ et autres éditeurs de texte

[^2]: Julien Dehut, En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation, 2018

interpréter un langage

id : 20201128143742
dernière édition :
type : inscription

Voici les différentes étapes pour interpréter un énoncé de langue naturelle formé de caractère (message électronique).

Premier niveau, la reconnaissance des mots : « on dispose généralement d'un lexique dans lequel les noms sont au singulier, les adjectifs au masculin singulier, les verbes à l'infinitif »[^1], mais les énoncés contiennent une variété plus importante avec les règles de grammaires, éventuelles erreurs d’orthographes voire avec des mots non intégrés au lexique. Pour limiter cela il convient de limiter le nombre de mots des agents : connecteurs logiques et vocabulaire d’une ontologie.

🔗 ontologie

Deuxième niveau, l’analyse syntaxique : on tente de comprendre la structure de l’énoncée, en général à l’échelle d’une phrase.

🔗 syntaxe du code

Troisième niveau, la sémantique : on cherche la significations des structures syntaxiques. Leur « interprétation consiste à exprimer cette signification dans un langage utilisable par un ordinateur. ».

Sens

Le niveau pragmatique :

« les messages véhiculent souvent autre chose que leur ‹ sens littéral ›  ; la situation dans laquelle ils sont émis, les rapports entre l'émetteur et le(s) récepteur(s) leur confèrent une signification particulière qui ne se trouve pas dans leur contenu propre »[^1]

[^1]: Adina Florea, Daniel Kayser, Stefan Pentiuc, Agents intelligents, 2002

javascript langage de programmation

id : 20200704153246
dernière édition :
type : programmation

Le langage de programmation JavaScript est apparu pour la première fois en 1996, au sein du navigateur Web Netscape Navigator. Il s’est peu à peu généraliser comme un langage de script 🔗, appelé CommonJs. Cela signifie qu’il peut être interprété par différents logiciels pour manipuler leurs fonctionnalités.

Le JavaScript a longtemps été un langage dédié au navigateurs web (pour gérer les intéractions dans les pages web), mais avec NodeJs il permet également de gérer le fonctionnement de machines. C’est un langage fullstack, permettant de gérer à la fois les processus d’intégreration des contenus et de génération. Il permet même de créer des applications desktop, de bureau, grâce à Electron 🔗.

Event loop

JavaScript est synchrone et mono-thread : chaque ligne sera exécutée l’une après l’autre en attendant la fin de l’exécution de la ligne précédente. Ainsi, JavaScript ne permet de faire qu’une seule chose à la fois. Toutefois, il est possible d’inscrire des fonctions asynchrones. Elles vont être mises à part, non exécutées dans la continuité : on passe à la fonction suivante sans exécutée celle-ci, alors placée dans la event loop, une boucle régulière qui va executer les tâches mises en attente. NodeJs tire le meilleur parti de ce fonctionnement.

Le JavaScript permet de gérer des événements comme un clic, un survol ou envoi de formulaire, ou même le passage d’une certaine période de temps (setTimeout). À partir de ces évènements, il peut lancer des processus asynchrones.

🔗 comportement logiciel

Les fonctions anonymes suivantes, sont asynchrones : la Event loop se chargera d’elles toutes les 5 secondes.

setTimeout(function() {
	// executé au bout de 5 secondes
}, 5000);

setInterval(function() {
	// executé toutes les 5 secondes
}, 5000);

🔗 callback, principe de programmation asynchrone 🔗 AJAX protocole de requêtes asynchrones

Prototypage

JavaScript est un langage entièrement orienté objet 🔗. Il fonctionne avec des prototypes : les bases du langage et ses principales interfaces sont fournies par des objets instanciés, modifiés, re-instanciés. Par exemple, String est une objet global de JavaScript permettant de construire des chaînes de caractère : toute chaîne de caractère JavaScript est un objet String. Les éléments des deux couples suivants ont exactement la même valeur :

var text = String('Lorem ipsum dolor sit amet, consectetur adipiscing elit.');
var textBis = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.';

var array = Array(42);
var arrayBis = [42];

Aux instances de String il est possible d’appliquer les méthodes comme split. Il est aussi possible d’ajouter des méthodes au prototype String ou même de créer son propre prototype qui héritera de l’objet des objets, Object.

function Personne(prenom, nom, age, genre) {
	this.prenom = prenom;
    this.nom = nom;
    this.age = age;
    this.genre = genre;
};
Personne.prototype.parler = function (paroles) {
    console.log(this.prenom + ' ' + this.nom + ' dit ' + paroles);
}

var guillaume = new Personne('Guillaume', 'Brioudes', 21, 'h');
var discours = guillaume.parler('Hello world!');

var valerie = new Personne('Valérie', 'Schlotter', 42, 'f');

function Table(shape, width) {
    this.action = '(╯°¤°)╯ ┻━┻';
}
graph LR
	discours -->|hérite de| guillaume
	parler -->|hérite de| Personne
	guillaume((guillaume)) -->|hérite de| Personne
	valerie((valerie)) -->|hérite de| Personne
	Personne((Personne)) -->|hérite de| Object((Object))
	Table((Table)) -->|hérite de| Object((Object))

Source : https://developer.mozilla.org/

JSDoc

id : 20211015141116
dernière édition :
type : documentation

JSDoc est un générateur d’index d’API 🔗. Il permet de générer une série de fichiers HTML où sont inscrit le code source documenté et les espaces de nom 🔗 qui y ont été identifiés. Ils sont catégorisés de deux manières, selon la portée des variables 🔗 :

  • global : accessibles depuis l’ensemble du code source (ex : authorName et findBook) ;
  • sous-espace : soumis à l’appel d’un objet 🔗 (ex : l’attribut nb et la méthode create depuis book).

Il sera ainsi plus aisé pour un lecteur d’appeler efficacement les variables.

/**
 * An author name
 * @default
 */
const authorName = 'Marguerite Yourcenar';

/**
 * Create a book
 * @param {number} bookId - Id of the book
 * @return {object} Book object
 */
function findBook(bookId) { … }

/** @namespace */

const book = {

    /**
     * Number of books
     * @default
     */
    nb: 30,

    /**
     * Create a book
     * @param {string} title - Title of the book
     * @param {string} author - Author name of the book
     * @param {string} content - Text of the book
     */
    create: function(title, author, content) { … }
}

Il peut être utile de fournir des exemples (avec le préfixe @example) de ce que peut retourner une fonction 🔗. Ainsi, on garanti à l’utilisateur de pouvoir correctement réutiliser l’extrant.

/**
 * Get type and id from a link string
 * @param {string} link - String between '[[]]' square brackets
 * @returns {object} - link type and target id
 * @example for link '[[a:20190519215026]]' returns { type: a, target: {id: 20200519215026 } }
 */

function normalizeLink (link) { … }

la donnée

id : 20200509195652
dernière édition :
type : processus

Une donnée est une unité d’information dans le contexte d’un programme.

Traitement

Elles sont prises dans un processus de transformation permanent[^1] :

  1. Données : extraites, on les liste, tri, caractérise avec des métadonnées 🔗 ;
  2. Code : elles sont sérialisées 🔗 pour former un environnement abstrait ;
  3. Interface : elles sont représentées sur une interface dont on peut les extraire.
flowchart LR
Données <--> Code <--> Interface <--> Données

Les données sont reconnues comme telle parce qu’elles intègrent un processus. Ainsi, il n’y a de données que lorsqu’elles sont massives, que lorsque l’on a intérêt à les traiter avec un algorithme 🔗. Pour cela on aura mis en place des moyens de stockage, traitement et représentation. Pour ce derniers point, les données ne peuvent être appréhendées par les humains que par le biais d’une interface. Il s’agit souvent d’un diagramme 🔗.

Neutralité

Les données sont neutres dans la mesure où tous les moyens mis en place pour leur traitement sont substituables.

🔗 qualités de l’écriture numérique

Toutefois, rien que le fait d’enregistrer les données nécessite de mettre en place un contexte de traitement (en vue de réaliser certains objectifs). Les données ne sont alors plus neutres. Les données peuvent éventuellement être formatées sans que l’on puisse les sérialiser 🔗 à nouveau.

Formatage

Les volumes de données peuvent adopter trois formats distincts dont dépendant leur structure 🔗 :

Format des données Fichiers types
Données structurées Fichiers de tableur, extractions de base de données
Données semi-structurées CSV, Json, XML, YAML
Données non structurées Textes, Image, fichiers complexes

Structurées et semi-structurées

Les données structurées permettent d’être régulier au niveau de la structure des objets 🔗 et de leur traitement, avec des accès conditionnels rapides. En revanche, elles ne permettent pas de traduire une pensée plus contingente, attachée au réel ou à la variété du Web. Les données semi-structurées ont leur intérêt dans le sens où il est possible d’être plus libre dans l’enregistrement des données.

« les bases de données traditionnelles (structurées) ne peuvent pas travailler sur des données dont le schéma n’est pas fixé a priori »[^2]

Or, la structure des données peut évoluer au cours de l’enregistrement ou du traitement. Les objets ne sont pas tous entièrement adaptés au schéma, parfois des valeurs nulles. Les attributs peuvent avoir une ou plusieurs valeurs et nécessitent d’être traités de la même manière.

L’architecture des données semi-structurées est implicite. Elle nécessite à la fois une analyse et une interprétation humaines des métadonnées, données pour établir une logique et enfin pouvoir passer à l’extraction des données et à leur traitement. Le schéma et les données on tendance à se confondre. Cette architecture est aussi non impérative, si sur la structure des objets, ni sur leurs valeurs.

Non structurées

Certains objets comme les BLOB, Binary Large Object (non formaté) ou les CLOB, Character Large Object (caractères encodés 🔗) sont complexes à interroger.

Les requêtes 🔗 sur des textes longs vont consister en une recherche de mot-clés. Dans le cas d’images, il va être nécessaire de faire un premier traitement de reconnaissance

Croisement

Le sens d’une donnée est si restreint que nous devons en relier plusieurs entre elles afin d’en dégager une information. Pour évaluer la pertinence du croisement entre plusieurs données, il nous faut également connaître le sujet de ce qui deviennent des fragments : nous devons disposer d’un contexte pour chacun (couple clé-valeur). Grâce à une métadonnée « Paris » n’est plus un nom de ville, mais un prénom qu’il est alors pertinent de relier à « 75 », un âge et non un numéro de département comme on en aurait jugé trop rapidement. Disons que ces données sont extraites d’une base « Utilisateurs » comme indiqué dans la documentation fournie. « Paris, 75 ans, est un utilisateur » ; voici une information exploitable.

Évaluation

Pour évaluer un volume de données, on dispose de cinq critères :

  • Volume
  • Variété (formats)
  • Vitesse (temps réel ? données chaudes (récentes) ou données froides (anciennes) ?)
  • Véracité
  • Valeur (pluvalue du traitement)

Ouverture

Des données ouvertes sont des données :

  • dont la licence est ouverte ;
  • dont on ne paie pas l’accès ;
  • qui sont lisibles avec des moyens accessibles au grand public (tableurs) ;
  • à jour ;
  • facile à télécharger, en une seule fois ;
  • sans contrainte d’accès, identification ou demande préalable ;
  • accessibles directement sur le web.

🔗 programmation utilisateur

[^1]: Prathyush, https://twitter.com/prathyvsh/status/1250739432929427456?s=20 [^2]: Tuyet Tram Dang Ngoc, Fédération de données semi-structurées avec XML, 2003

la loi du code

id : 20201025084447
dernière édition :
type : processus
mots-clés : politique

Le code détermine l’accès à l’information (en tant qu’architexte 🔗 ) et s’il change, l’espace numérique change également en tant qu’espace politique.

« Du code, c’est du texte – jusqu’à ce qu’il détermine le cadre de vie des citoyens. Alors, le code devient loi. »[^2]

« Le code régule. Il met en place certaines valeurs plutôt que d’autres. Il rend possible ou interdit certaines libertés. Il protège la vie privée ou favorise la surveillance. Des gens choisissent la manière dont le code effectue cela. Des gens écrivent ce code. »[^1]

Responsabilité des personnes

Le code est écrit par des humains pour une finalité humaine. L’étude critique d’un logiciel, d’un programme, d’une application va au-delà de l’analyse de ses performances, de ses fonctionnalités et tente d’étudier son impact sur les utilisateurs (effets « extra-fonctionnels »).

« La question n’est donc pas de savoir qui décidera de la manière dont le cyberespace est régulé : ce seront les codeurs. La seule question est de savoir si nous aurons collectivement un rôle dans leur choix – et donc dans la manière dont ces valeurs sont garanties – ou si nous laisserons aux codeurs le soin de choisir nos valeurs à notre place »[^1]

« En tant que conceptrices et concepteurs de ces programmes, de ces algorithmes, notre responsabilité est de veiller à ce que nos créations servent à aider, à libérer. De refuser de produire des outils conçus pour exploiter, asservir, réprimer ou polluer »[^3]

« Ce sont eux, ces ‹ codeurs › et ‹ codeuses ›, ces ‹ agilistes ›, ‹ CTO ›, ‹ Tech lead ›, ‹ Lead Dev ›, et consorts, ce sont eux qui ‹ implémentent ces valeurs ›, eux qui ‹ garantissent ou empêchent certaines ‹ libertés ›. Ce sont eux qui nous laissent aussi, et ainsi, entrevoir enfin la possibilité de choix collectifs ‹ dans la manière dont ces valeurs sont garanties ›. »[^4]

Réglementation

Le protocole TCP/IP qui permet les échanges sur le Web est neutre, n’identifie pas ses utilisateurs où les données qu’il transporte rendant ainsi l’espionnage complexe. Le Web est ainsi difficilement régulable. Toutefois, cette liberté ne peut être garantie par le code : il n’est pas fixe et le protocole TCP/IP peut être modifié, remplacé. Certaines institutions ont tout intérêt à le faire.

La question n’est pas « faut-il ou non réglementer ? » puisque l’environnement numérique est par essence le croisement de flux régulés par des instructions machines. La question est « comment faut-il réguler ? comment prendre cette décision ? ». Les intérêt de cette régulation ne doivent pas être privés, mais pour le bien commun.

Les développeur·ses

La formation et la sensibilisation des développeuses et développeurs est cruciale pour éviter qu’ils ne développent des interfaces dangereuses. Soit qu’elles emprisonnent les utilisateurs, qu’elles récupèrent leurs données personnelles, qu’elles se substituent à d’autres usages pour les limiter…

[^1]: Lawrence Lessig, Code and Other Laws of Cyberspace, 2000 [^2]: Louis-Olivier Brassard, Le code, c’est la loi, 2020 [^3]: https://onestla.tech/ [^4]: Olivier Ertzscheid Code is Outlaw. C’est la lutte digitale et la grève reconduc’stream, 2019

la portée des variables

id : 20200522093949
dernière édition :
type : architecture
mots-clés : technique

Les variables (et constantes) 🔗 ont une portée : leur valeur persiste différemment d’un langage de programmation à une autre au sein de l’espace de nom 🔗. La portée varie selon l’encapsulation 🔗 des données dans une fonction au d’autres structures de contrôle 🔗. Contrôler la portée des variables, c’est éviter des appels et affectations inattendues, des effets de bord 🔗.

Une variable (ou constante) 🔗 globale est une variable dont la définition peut être atteinte à l’extérieur du corps de toute structure de contrôle 🔗. C’est un intrant, sans qu’elle n’ait besoin d’être passé en paramètre. Ainsi, on peut utiliser sa valeur n’importe où dans le fichier courant, voire l’ensemble des fichiers combinés (par transclusion 🔗).

Au contraire, des variables 🔗 locales ont une portée limitée. Elles sont encapsulées 🔗 pour protéger leur valeur et limiter leur occupation de l’espace de nom 🔗. Ainsi, dans plusieurs structures de contrôle 🔗 on peut utiliser les mêmes noms.

PHP

En PHP, on voit ci-dessous qu’une variable externe à une fonction n’a pas de valeur en son sein, pas plus qu’une variable déclarée dans la fonction n’a de valeur à l’extérieur.

$nbExterne =  5;
echo $nbExterne; // --> 5

function triple()  {
    echo $nbExterne * 3; // -->  Undefined variable
    $nbInterne = 42;
}
triple(); // --> 0

echo $nbInterne; // -->  Undefined variable

Il faut préciser avec le mot-clé global que la valeur de la variable vaut et peut être modifiée dans l’ensemble de l’espace de nom, y compris les fichiers combinés.

$nbExterne = 5;

function  triple()  {
    global $nbExterne;
    $nbExterne *= 3;
    echo $nbExterne;
}
triple(); // --> 15
echo $nbExterne; // --> 15

JavaScript

Le JavaScript est plus complexe avec une variété de déclarations et un jeu subtil des encapsulations.

Un objet déclaré avec le mot-clé const ne peut être réaffecté (on ne peut modifier la valeur de l’artefact), mais est mutable (on peut toujours modifier ses propriétés), sauf si on utilise la méthode Object.freeze().

Toute déclaration varou const est par défaut globale, sauf si elle est encapsulée au sein d’une fonction comme le montre l’exemple ci-dessous.

const multiplicateur = 2;
var nbExterne = 5;

function tripe() {
    console.log(nbExterne * multiplicateur);
    var nbInterne = 42;
}
tripe(); // --> 10

console.log(nbInterne); // --> Uncaught ReferenceError

Une variable déclarée avec le mot-clé let ne peut être appelée en dehors de la structure de contrôle dans laquelle elle a été encapsulée :

for (const i of [20, 30, 40, 50]) {
 	let plus = 1;
	var result =  i + plus;
 	console.log(result); // --> 21, 31, 41, 51
}

console.log(result); // --> 51
console.log(plus); // --> Uncaught ReferenceError

function letTest() {
 	let x = 1;
	if (true) {
    	let x = 2;  // variable différente
    	console.log(x); // --> 2
  	}
  	console.log(x); // --> 1
}

letTest()

Pour éviter d’écraser les variables par inadvertance ou de se retrouver avec des valeurs incertaines, les développeurs JavaScript ont pour convention d’utiliser systématiquement les fonctions anonymes encapsulées. Elles sont déclarées sans nom et immédiatement exécutées et permettent de « scope », d’emprisonner, les valeurs des variables qu’elles contiennent.

// valeurs globales

(function()  {
	// valeur isolées
})();

De plus, tout ce qui est attaché à window devient une variable globale du navigateur.

var nbExterne = 42;

(function() {
    var prive = 2;
    var nbInterne = nbExterne * prive;
    window.nbInterne = nbInterne;
})();

console.log(nbInterne); // --> 84

la typographie comme interface

id : 20200621083005
dernière édition :
type : inscription

🔗 typographie

Face au trop d'information du web (« infobésité ») « C’est la tâche du typographe de diviser, d’organiser et d’interpréter cette masse d’information »[^1]. Ainsi il faut imaginer la typographie comme une interface et un dispositif d'éditorialisation, soit comme un matériau plus de design que simplement d'esthétique : « Choisir une police n’est pas de la typographie »[^1].

« Optimiser la typographie consiste à optimiser la lisibilité, l’accessibilité, l’usabilité, l’équilibre graphique général »[^2]

🔗 inscription du code

Ce travail de design se joue sur deux échelles :

  • macro-typographique : structure générale d’un texte
  • micro-typographique : détails des caractères et espacement des mots

🔗 règles typographiques

[^1]: Emil Ruder, Web Design is 95% Typography, traduit sur la référence [^2] [^2]: Oliver Reichenstein, Le web, 95% de typographie, 2013 [^3]: Emil Ruder, Typographie, 1981

la vérité que nous enseigne le big data

id : 20200619130655
dernière édition :
type : processus

🔗 la donnée 🔗 la loi du code

« l’humain a érigé une instance à nous dire la vérité en toutes choses »[^1]. Le big data porté par l’intelligence artificielle a pour mission « d’expertiser des états du réel »[^1] dans le mesure où il échappe à nos capacités cognitives. Antoinette Rouvroy parle d’idéologie du big data qui nous « dispenserait de la représentation »[^2]. Dans les deux cas il s’agit d’observer le « vrai monde ».

Antoinette Rouvroy et Éric Sadin notent toutefois que cette réalité qui est décrite n’est pas complète. Il l’oppose à l’« exactitude des choses ». On ne peut assimiler ce dont les intelligence artificielles nous rendent compte à des faits : Elle explique que la charge de sécurité est souvent trop lourde pour exploiter des données personnelles alors les opérateurs sont obligés d’anonymiser, c’est à dire de « désindexer, décontextualiser, c’est à dire rendre les données amnésiques de leurs sources, amnésiques de leurs conditions de production. Hors rendre les données amnésiques de leurs conditions de production : on les fait apparaître comme des faits neutres »[^2]. On ne peut plus vérifier leur validité étant donné la perte de contexte. S’il faut revenir aux sources de ces données, on entre dans un « processus d’éditorialisation »[^2].

🔗 éditorialisation

Le risque du big data, c’est la corrélation. « Toute vérité a une valeur performative »[^1] : une annonce du logiciel fait autorité et déclenche une réaction de l’humain, sans qu’il est nécessairement la possibilité d’évaluer ce qui devrait rester une suggestion. L’idéologie la transforme en injonction. Ces injonctions viennent selon Éric Sadin organiser les espaces communs, la société et son histoire. Le big data s’inscrit dans nos sociétés et deviens du « long data »[^6], des données historiques.

Éric Sadin voit l’origine de l’idéologie du big data dans ce qu’il appelle le technocapitalisme : la « monétisation de tous nos comportement, d’un marchandisation intégrale de la vie, d’une organisation algorithmique de la société ».

[^1]: Éric Sadin dans la vidéo l’asservissement par l’Intelligence Artificielle ?, 2018, de Thinkerview [^2]: Antoinette Rouvroy dans la vidéo Rencontre avec Antoinette Rouvroy : gouvernementalité algorithmique et idéologie des big data, 2018, de Le Mouton Numérique [^6]: Dominique Vinck, Humanités numériques: la culture face aux nouvelles technologies, 2016, p.23

langages compilés ou interprétés

id : 20200718182015
dernière édition :
type : processus

Ce sont deux grandes familles de langages, différenciés par leur traitement par la machine. Ça n’est pas une dichotomie parfaite ; il y a une porosité dans le mesure où certaines instructions des langages interprétés nécessitent une compilation. C’est le cas notamment en PHP.

Langages interprétés

Exemples : JavaScript, Java, Python

Ce sont des langages de script 🔗.

Le même code source pourra fonctionner directement sur tout ordinateur qui possède le logiciel d’interprétation (runtime 🔗) correspondant au langage utilisé (ex : JavaScript → NodeJs). Ce logiciel d’interprétation va compiler le code ligne pas ligne, à la volée, just in time et permettre son execution par le CPU. C’est une chaîne de dépendances qui va ralentir l’exécution et éventuellement provoquer du bruit, des dysfonctionnements. Toutefois, les instructions peuvent être exécutées dès leur saisie, sans le délais de traitement du processus de compilation. C’est utile pour traiter rapidement les erreurs, synchroniser des logiciels.

graph LR
	codesouce[code source]
    interpreteur[interpréteur]
    donneeentree[données d'entrée]
    donneesotie[données de sortie]
    
    codesouce --> interpreteur
    donneeentree --> interpreteur
    interpreteur --> donneesotie

Langages compilés

Exemples : C, C++

Les langages compilés doivent être « traduits » en code objet (langage machine binaire, « code natif » ou RTL, Register Transfer Language, proche de l’assembleur) pour pouvoir être exécutés. Ce code est alors directement injecté dans le CPU (dans les couches basses du système 🔗), sans dépendance supplémentaire. Il est donc plus rapidement. Il faut toutefois faire face à des problématiques de version du système d’exploitation.

graph TD
	codesouce[code source]
    compilateur[compilateur]
    binaire[code machine binaire]
    sysexploitation[système d'exploitation]
    donneeentree[données d'entrée]
    donneesotie[données de sortie]
    
    codesouce --> compilateur
    compilateur --> binaire
    binaire --> sysexploitation
    donneeentree --> sysexploitation
    sysexploitation --> donneesotie

On parle parfois de « compilation à la volée », soit l’interprétation ligne par ligne, chacune compilées.

Source : http://www.france-ioi.org/algo/course.php?idChapter=561&idCourse=2368

langages de balisage

id : 20210205230127
dernière édition :
type : architecture
mots-clés : technique, REVUE

Les langages de balisage permettent d’enrichir du texte en apportant du contexte, du sens et de la structure. On peut ainsi baliser du texte devenu un set de des données que l’on peut intégrer dans un fichier ou pour les transférer (AJAX 🔗). Ils reposent sur l’utilisation de balises permettant d’encadrer des chaînes de caractères. Ainsi, elles séquencent le flux du texte. Elles peuvent facilement être retrouvées dans le texte via une analyse syntaxique 🔗 permettant ainsi de traiter automatiquement le contenu enchâssé, ses attributs.

🔗 corps de texte balisé, sémantisé, interactif

Les balises peuvent être délimitées de différentes manières. Le plus souvent par des chevrons <> avec les langages dérivés du SGML. Ce peut être avec des antislash \ comme en LaTeX. Ce sont des unités syntaxiques.

<balise attribut="valeur">contenu enchâssé</balise>

Granularité

La granularité est le détail des données. Dans les exemples ci-dessous, le premier à une granularité plus élevée. C’est à dire que l’on peut cibler les me^me éléments avec plus de finesse.

<introduction>
    <titre>Titre de mon document</titre>
    <ss-titre>Sous titre de mon document</ss-titre>
</introduction>

<introduction>Titre de mon document - Sous titre de mon document</titre></introduction>

Historique

Les langages de balisage ont d’abord servit à documenter le code source. IBM a été la première entreprise à devoir imaginer documenter ses nombreux travaux informatiques. Cela a commencé avec la GML. Les SGML apporte les feuilles de style : la mise en en page ne dépend plus de la structure logique du document, mais de règles externes adaptées à un support donné.

graph
GML --> SGML
SGML --> HTML
SGML --> TEI
SGML --> XML
XML --> XHTML
XML --> RDF
XML --> RSS

Schéma de données

https://fr.wikipedia.org/wiki/Standard_Generalized_Markup_Language https://fr.wikipedia.org/wiki/Document_type_definition https://fr.wikipedia.org/wiki/Liste_des_entit%C3%A9s_de_caract%C3%A8re_de_XML_et_HTML https://fr.wikipedia.org/wiki/Text_Encoding_Initiative

langages de balisage léger

id : 20200619133835
dernière édition :
type : inscription
mots-clés : technique

Les langages de balisage léger (lightweight markup languages) sont inscrits dans des fichiers de texte brut 🔗, profitant de toutes ses caractéristiques (information non périssable, facilement analysable, lisible…). Ils permettent de générer rapidement un document sémantisé 🔗 avec un effort minimum d’inscription, sans connaissances techniques particulières.

Le Markdown 🔗 et le Textile sont des exemples de langage de balisage léger créés en 2004. Leur syntaxe 🔗 sont si légères (facile à lire et à écrire) que les formatés avec eux peuvent être lus « en l’état sans donner l’impression d’avoir été balisé ou formaté par des instructions particulières »[^1].

Ce balisage permet de déclarer certains styles de caractère (italique, gras) et même quelques éléments sémantiques (niveaux de titres, insertion de code). Ces fichiers sont ainsi préparés pour un affichage et un export graphique (PDF, DOCX, ODT) et/ou sémantique 🔗 (HTML, LaTeX).

Variété

Langage Usage
Markdown Article de blog et documentation
AsciiDoc Documents publiables
BBCode Forums de discussion
reStructuredText Documentation Python
Wikitexte, Wikicréole Rédaction pages des logiciels de wiki

[^1]: Wikipédia, Markdown, lu le 19/06/2020

langages de programmation

id : 20200704135046
dernière édition :
type : inscription
mots-clés : Anthony Masure

Un langage de programmation est un langage formel (« système de signes composé d’un vocabulaire et d’une syntaxe » 🔗 dépourvu des « notions d’ambiguïté, de doute, d’incompréhension »[^1]) permettant d’implémenter des algorithmes 🔗 prescrits à des machines. Il s’agit d’architextes 🔗, à la fois compréhensibles par les humains et les machines. Il est inscrit dans des fichiers de texte brut 🔗.

Apparence

Sans considérer la typographie avec laquelle on peut les lire, les langages de programmation ont une apparence propre. L’apparence du Python diffère largement du JavaScript qui ressemble au PHP, les deux étant dérivés du C. Ainsi, la généalogie des langages de programmation est importante pour comprendre les logiques qu’ils permettent de mettre en place.

« nous devons penser en termes, non pas de langues, mais de familles de langues […] systématiser leur conception de sorte qu'une nouvelle langue soit un point choisi dans un espace bien cartographié, plutôt qu'une construction laborieusement conçue »[^2] (p.164)

Cette structure physique est une aide à la compréhension de leur logique ; l’inscription du code 🔗 influx largement sur la logique que l’on en déduit.

Utilisation

Un langage de programmation se limite à ce qui peut être analysé et exécuté par un environnement d’exécution 🔗 donné. Il est accompagné par des conventions entre les développeurs, ajoutées à des documentations dédiées. Pour un même langage, l’environnement d’exécution peut limiter son utilisation. Par exemple, il peut s’agir d’un écart de version. Il y a plusieurs moyens et méthodes pour implémenter un même algorithme.

« Ce cadre dicte les règles concernant l’utilisation des noms créés par l’utilisateur et les conventions relatives à la caractérisation des relations fonctionnelles […] La plupart des langages de programmation sont en partie une façon d’exprimer des choses en termes d’autres choses […] Ces règles varient considérablement d’une langue à l’autre, et souvent, même au sein d’une même langue, il peut y avoir différentes conventions pour différentes classes de noms, avec des quasi-analogies qui se rapprochent de manière irritante de l’exactitude »[^2] (p.157)

Pour implémenter ses algorithmes, l’utilisateur du langage droit inscrire certaines expressions. Certaines sont propres au langage tandis qu’il doit en inventer d’autres.

« un utilisateur peut inventer des noms, en obéissant à certaines règles concernant les contextes dans lesquels le nom est utilisé et leur relation avec les segments textuels qui introduisent, définissent, déclarent ou limitent autrement son utilisation »[^2] (p.157)

Choix du langage

Les langages de programmation sont interchangeables : ils ne sont qu’un outil parmi d’autres pour exprimer une solution (circuit logique) pour un problème donné. On choisi un langage de programmation pour ses paradigmes 🔗 et surtout pour l’environnement de développement 🔗 auquel il est lié.

🔗 strates des langages de programmation

Généalogie

Les langages de programmation sont souvent des interfaces pour faire appel à d’autres langages. Par exemple, le langage PHP est développé en langage C.

🔗 strates des langages de programmation

graph TD
    C --> PHP
    C --> C++
    C++ --> Java
    C++ --> C#
    
    C --> NodeJs((NodeJs))
    C++ --> NodeJs
    JavaScript --> NodeJs
    JavaScript --> AngularJs((AngularJs))

[^1]: Anthony Masure, Le design des programmes, 2014 [^2]: Peter J. Landin, The Next 700 Programming Languages

langages informatiques dédiés à la documentation

id : 20210523081627
dernière édition :
type : inscription

Ce sont des langages de balisage léger 🔗.

Langages

Markdown

Le Markdown est le plus populaire. Il a été conçu pour le blogging et est donc spécialisé dans le balisage de page web avec un minimum de mise en forme : titre, gras, italique, citation, tableau et bloc de code. Toutefois, il a bénéficié avec les années de différentes extensions (sur/sous-lignement, note de bas de page, YAML Front Matter, wikilinks 🔗…) pour générer des PDF et autres documents texte. Le Pandoc Markdown est par exemple optimisé pour l’écriture académique. L’utilisation de ces nouvelles formes de syntaxique dépend de l’interpréteur utilisé.

AsciiDoc

L’AsciiDoc est un langage plus polyvalent, permettant de réaliser des documents élaborés. Son seul interpréteur est Asciidoctor ouvert à différents runtime comme Ruby ou NodeJs.

reStructuredText

Le reStructuredText est interprété par le logiciel Docutils et généralement pour générer la documentation de programmes implémentés en Python.

Lecture

Le Markdown ne permet de réaliser que peu de mise en forme. Toutefois, la légèreté de sa syntaxe 🔗, l’absence de mots clé permettent de concentrer le contenu des fichiers canoniques (originaux) sur le sens du document, et non de son export. Avec le Markdown, le lecteur n’a pas à différencier les expressions humaines des expressions machines. Il est en revanche nécessaire en AsciiDoc et reStructuredText de mêler les deux langages comme ci-dessous pour créer des notes de bas de page en AsciiDoc.

Voici un paragraphefootnote:[Je me confond avec le texte] d’exemple inscrit en AsciiDoc.

le design

id : 20200515185607
dernière édition :
type : undefined

Le design est une démarche créatrice concentrée sur le palpable et visant à répondre à un besoin humain étudié. La formule « dessein + dessin = design » l'exprime élégamment. Un dessein est une « conception par l’esprit d'un but à atteindre, d'une fin à réaliser » (CNRTL) : plus qu'une intention c'est un processus intellectuel.

« Le design ce n’est pas l’apparence et le ressenti. C’est comment cela fonctionne. » (Steve Jobs)

Le design est d’après Stéphane Vial :

  • une esthétique (beauté formelle)
  • une sociologie (dans les mains et les esprits, par les interactions sociales)
  • un événement (expérience du monde)

Dieter Rams, cité par Antony Masure[^2], ajoute qu’un « bon design est inventif, […] rend le produit utile, […] aide le produit à être compris, […] est honnête, […] soutenable, […] dure longtemps, […] est cohérent jusqu’au moindre détail, […] tient compte de l’environnement, […] est aussi peu design que possible ».

Réguler la société

« Prenons un feu rouge : pourquoi il y a trois lumières ? On pourrait mettre une lumière avec trois ampoules qui changent. On s’est rendu compte qu’il faut doubler une information pour qu’elle soit compréhensible et sûre, et donc changer aussi la position de la lumière »[^1]

Pour cela le design est profondément ancré dans le monde et ses usages industriels

https://scolaire.loupbrun.ca/conferences/philo-design/#/%2Fconferences%2Fphilo-design%2F14%2F

[^1]: Annabelle Laurent, La conscience d'une pollution mentale créée par le numérique émerge, 2017 [^2]: Anthony Masure, Le design des programmes, 2014

les versions historiques du web

id : 20200617210141
dernière édition :
type : processus

Le web est un mode de circulation des contenus sur le réseau international Internet. Il a connu plusieurs paradigmes :

🔗 notion de paradigme

  • Web 1.0, paradigme de la bibliothèque : web de documents avec l'idée que les navigateurs web sont autant des outils de lecture que des outils d'édition. « Les notions de lecture-écriture sont indissociables pour assurer la circulation de l’information bilatérale »[^1].
  • Web 2.0 : web de plateforme avec l’écriture collaborative documents devenus des données. « Au-delà de l’écriture explicite (texte) par les utilisateurs, ce sont donc toutes leurs interactions qui deviennent autant d’écritures rejoignant les données utilisables par les logiciels du web »[^1].
  • Web 3.0, paradigme du web sémantique : web sémantique dans la mesure où des logiciels sont maintenant installés sur les serveurs et les clients pour traiter la data en circulation sur le réseau.

Ces changements sont causés par un glissement de la valeur : matériel (hardware) → logiciel (software) → données (data) → données liées (linked data). Ainsi, nous allons vers le big-data.

🔗 espace numérique

Web documentaire Web de données
Objet page ressource
Protocole HTTP HTTP
Norme de fichier XML HTML RDF
Identification URL URI
Circulation liens hypertexte propriétés

Le Web écrase tout par son processus éditorial 🔗.

Le Web n’est pas « non structuré », mais il est constitué une très grande variété de structures. Cela rend son traitement très complexe (imprévisible).

[^1]: E.S Michael et V.R Marcello, Pratiques de l'édition numérique, 2014

licence logiciel

id : 20210517204416
dernière édition :
type : processus
mots-clés : politique

Droit d’auteur

Le droit d’auteur français s’applique aux logiciels. Ils sont protégé dès leur création, sans formalité, par les droits patrimoniaux (pour rémunération), pour une durée de 70 ans à compter du premier janvier suivant le décès de l’auteur. Tout au partie de ces droits peuvent être vendus (temporairement ou non), perdus. C’est un copyright (mention non reconnue en droit français) automatique. Les droits moraux ne sont toutefois pas tous garantis (droit de retrait, de divulgation), mais on garde le droit de paternité et de respect de l’intégrité.

Son protégés le nom, l’interface, la documentation 🔗, les prototypes, le code source et le résultat de sa compilation (code objet).

Application difficile

Il est difficile de faire valoir son droit d’auteur dans le domaine du logiciel. Il n’est en effet pas possible de protéger une fonctionnalité, un algorithme 🔗 par le droit d’auteur. Le simple fait de faire varier les méthodes d’implémentation (architecture, dictionnaire) et les éléments de la structure logicielle 🔗 permettent de le contourner (même s’il reste les brevets).

L’auteur

L’auteur du logiciel est celui ou celle qui l’a développé ou bien, s’il s’agit d’une équipe, de la personne qui l’a édité (publication, divulgation), commandé, ou qui emploie ces collaborateurs.

Licence

La licence d’un logiciel exprime (en plusieurs versions, texte abrégé ou légal) les droits de ses développeurs. Elle se superpose aux droits patrimoniaux acquis d’office par l’auteur. Elle ne peut aller contre les droits moraux.

La licence peut annoncer l’abandon par l’auteur de tous ses droits patrimoniaux, relatifs à sa rémunération. Ces licences sont du domaine du copyleft. Elles facilitent la diffusion des logiciels du domaine du logiciel libre ou open source 🔗. Elles ne s’opposent pas au droit d’auteur, mais sont particulièrement soucieuses du droit des utilisateurs : liberté d’utiliser, d’étudier, de modifier et de diffuser.

La GNU General Public License 3.0 (GPLv3) est l’une des licences copyleft les plus utilisées et les plus efficace. Les liences Creative Commons ne permettent pas de protéger les logiciels efficacement, « ne contiennent pas de termes spécifiques au sujet de la distribution du code source »^1

liste des références

id : 20210408140818
dernière édition :
type : inscription

Les index sont des listes ordonnées de références. Les éléments suivants peuvent être/contenir des index, mais sans s’y limiter.

  • glossaire : liste de définitions dans un domaine particulier
  • lexique : ouvrage autonome contenant des définitions de termes
  • sommaire : liste brève des parties d’un document (plan ?)
  • table (des matières, des figures, des tableaux…) : liste exhaustive des éléments d’un document

littératie numérique

id : 20200707175829
dernière édition :
type : processus
mots-clés : Marcello V.R.

La littératie est « l’aptitude à comprendre et à utiliser l’information écrite dans la vie courante […] en vue d’atteindre des buts personnels et d'étendre ses connaissances et ses capacités »[^1]. C’est la capacité à lire, à accéder à un document, à une information.

« Cette culture [de l’édition numérique] n’est rien d’autre que la littératie numérique qui ajoute au savoir-lire-et-écrire la maîtrise du milieu d’écriture et une capacité à inscrire l’espace autant qu’à le structurer. Il s’agit à la fois de savoir évoluer dans cet environnement (l’habiter) et de le faire évoluer (le designer). »[^2]

On parle désormais de translittératie quand il s’agit d’interagir en différents endroits, entre une documentation variée (forme, canaux) et une multitude de plateformes (réseaux sociaux et autres services en ligne). Parmi les compétences attendues en littératie, on trouve l’« alphabétisme informatique »

🔗 DigComp, évaluation des compétences numériques

Le mal du siècle en matière de documentation est en effet la perdition des objets et du savoir-lire. On relève un analphabétisme numérique, une incapacité à lire du code, à utiliser un terminal de commandes ; c’est un effet largement soutenu par les outils comme les logiciels de traitement de texte et autres interfaces graphiques donnant une illusion de littératie.

🔗 enjeux politiques de l'écriture numérique

[^1]: OCDE, La littératie à l’ère de l’information, [^2]: Marcello V.R, Nicolas Sauret, Antoine Fauchier, Margot Mellet, Écrire les SHS en environnement numérique. L’éditeur de texte Stylo, 2020

livre numérique

id : 20200701110951
dernière édition :
type : inscription

Ce n’est qu’au Moyen-Âge que le livre prend la forme (du « codex ») que nous avons désormais l’habitude de voir. Avant cela, les écris étaient inscrits sur des rouleaux (forme dite « volumen »).

Hypertexte

Le passage du volumen (linéarité) au codex (tabularité[^2]) a permis d’intégrer les notions hypertextes : les pages sont des unités qu’il est possible de dénombrer (et donc d’identifier précisément) et d’annoter (liens internes, notes de bas de page).

🔗 hypertexte hypertexte

Sur le web

Toutefois, ce que ce que l’on considère aujourd’hui comme le principal domaine de l’hypertexte, le web, s’apparente d’avantage à un volumen : les pages web défilent (certes verticalement et non plus horizontalement) et les seules unités qu’il est possible d’identifier sont des balises (ancres) cachées dans le code source de la page.

🔗 corps de texte balisé, sémantisé, interactif

Édition

🔗 édition numérique

« éditer un ouvrage entraîne la conception du système de publication, en fonction du type de publication et des contraintes inhérentes à la structure ou à la diffusion »[^1]

La forme de la page (comme on la trouve en fond sur Word ou LibreOffice Writer) n’a pas de sens sur écran, sinon pour vérifier la mise en page d’un contenu à imprimer sur support physique.

🔗 paradigme de l’imprimé

Hors, lorsque nous travaillons pour et dans un format numérique (par nature suffisamment flexible, modulaire pour se détacher des supports physiques finis comme le papier ou le codex). La rédaction du livre doit donc être entièrement repensée.

[^1]: Antoine Fauchié, Vers un système modulaire de publication : éditer avec le numérique, 2019 [^2]: « possibilité pour le lecteur d'accéder à des données visuelles dans l'ordre qu'il choisit » Christian Vandendorpe, Du papyrus à l'hypertexte, 1999

logiciel libre et logiciel open source

id : 20200710204125
dernière édition :
type : processus
mots-clés : politique

« Logiciel libre » est une expression largement galvaudée. Les logiciels libres (free) tendent à être confondus avec les logiciels open source (open) malgré leurs différences éthiques et ontologiques (de nature). On les confond dans le domaine du « LOS », Libre Open Source, lancé dans les années 80.

« Les deux expressions décrivent à peu près la même catégorie de logiciel, mais elles représentent des points de vue basés sur des valeurs fondamentalement différentes. L’open source est une méthodologie de développement ; le logiciel libre est un mouvement de société »[^1]

On reconnaît dans ce milieu militant, hacker 🔗, plusieurs personnalités, dont Richard Stallman (projet GNU, Free Software Fondation…) et Linus Torvalds (développement de Linux, Git…). Le premier est mû par un projet politique tandis que le second s’épanouis dans un projet en communauté avec un intérêt intellectuel et pratique. Ce sont deux intentions différentes à l’origine du logiciel libre et du logiciel open source. La liberté de créer à réunit de nombreuses personnes qui n’étaient pas nécessairement prêtes à se lancer dans une démarche militante. De nombreux autodidactes se sont lancé dans des projets grandioses avant de mettre à profit leur savoir dans des projets privés.

Logiciel libre

Le logiciel libre se veut respecter « les libertés essentielles de l’utilisateur : la liberté de l’utiliser, de l’étudier, de le modifier et d’en redistribuer des copies, modifiées ou non »[^1]. Free ne veut pas dire gratuit (la maintenance peut d’ailleurs être rémunérée), mais renvoie à la liberté (très simple) de (re)utilisation. Ainsi, le logiciel libre est une démarche politique des développeurs, conscients que, si le matériel est désormais accessible à tous, le logiciel reste une problématique sociale et d’émancipation. Il est toujours cher et soumis au bon vouloir de grandes multinationales.

Open source

Le logiciel open source (OSS, Open Source Software) se veut transparent et collaboratif. S’il est vrai que le code source du logiciel libre est également public et est l’œuvre d’une équipe de développement, c’est dans un tout autre dessein que l’open source grandit, dans un esprit (projet) d’entreprise et d’innovation et d’efficacité technique[^3].

C’est une logique pragmatique des organisations et administrations consistant à ouvrir le code de leurs logiciels pour obtenir les contributions (utilisation, suggestion, maintenance…) des internautes. C’est une amélioration continue favorisant « la fabrication ou la possession de logiciels puissants et fiables »[^1] selon la Loi de Linus. Elle dispose qu’une équipe de testeurs/développeurs suffisamment nombreuse peut arriver à bout de tous les bugs : le correctif sera évident pour l’un d’entre eux.

« Le mouvement du logiciel open source s’est écarté des aspects sociopolitiques du mouvement du logiciel libre pour se concentrer sur les bénéfices pratiques du développement logiciel et encourager des applications créatives et commerciales plus larges »[^2]

la liberté n’est pas du côté des utilisateur, mais de celle des développeurs.

Mouvements politiques

Le logiciel libre et le logiciel open source sont deux démarches communautaires d’utilité publique, mais dans deux directions radicalement différentes.

Libre marxiste

Le logiciel libre ne s’oppose ni au code source ouvert (open source), ni au code source fermé. « l’ennemi est le logiciel privateur »[^1], le logiciel d’un propriétaire qui enferme les utilisateurs dans son écosystème et menaçant à tout instant de les priver de leurs travail. On retrouve là le schéma marxiste du prolétaire, dépossédé de ses moyens de production, pris par le capitaliste rentier (propriété lucrative).

Ainsi, on retrouve parmi les logiciels libres des alternatives aux grands noms du logiciel propriétaire liberticide : Microsoft Word → Libre Office Writer ; Adobe Photoshop → Gimp ; Adobe Illustrator → Inkscape ; Adobe InDesign → Scribus ; Google Chrome → Firefox… Ils sont liberticides par leurs systèmes d’abonnement, leurs formats de fichier fermés et plus généralement leur domination des usages. Le logiciel libre se propose comme une solution pour les utilisateurs de pouvoir créer sans faire appel à ces logiciels.

Open capitaliste

Pour défendre les valeurs du libre, l’équipe d’un logiciel ne peut se contenter d’ouvrir son code source, mais elle doit se donner les moyens d’établir de la liberté durablement pour son logiciel. Le projet open source est quant à lui bien plus éphémère, soumis à des mouvements de mode. Ainsi on retrouve de nombreuses dépendances logicielles 🔗 sans cesse améliorées avant d’être remplacées au bout de quelques années par un autre projet plus influant.

« La plupart des discussions sur l’open source ne s’intéressent pas au bien et au mal, seulement à la popularité et au succès. »[^1]

Les paradigmes changeant sans cesse avec des développeurs sous la pression du changement. L’open source ne s’adresse pas à l’utilisateur. Il s’en détourne quitte à le perdre comme le ferait un logiciel propriétaire. Cela n’est pas liberté, mais une mise en concurrence permanente des communauté et des organisations derrière elles. L’ouverture du code source vise plus un accroissement de capital qu’une mise en commun ; c’est à qui remportera le plus de succès et non de pérennité dans un pure esprit capitaliste.

🔗 travail gratuit, économie du web de plateforme

Maintenance

La nature décentralisée de l’open source – réalisé à la fois par tout le monde et par personne – rend instable sa maintenance 🔗.

Comme avec la Linux Fondation pour logiciel libre, les projets open source basé sur NodeJs tendent à se pérenniser au sein de la OpenJS Fondation. Le nom laisse encore quelques doutes. Pourtant ces dépendances logicielles deviennent peu à peu les bases de grandes infrastructures utiles à des milliers de personnes. Leur maintenance devient impérative, sans quoi il se peut que de nombreux utilisateurs ne puissent plus utiliser leurs outils voire deviennent sensibles à des attaques. Ils se retrouvent alors pris au piège, faute de pérennité, malgré les bonnes intentions de la communauté.

« Le logiciel open source est créé et utilisé aujourd’hui à une vitesse jamais vue auparavant. Beaucoup de projets open source sont en train d’expérimenter la difficile transition d’une création désintéressée à une infrastructure publique essentielle. »[^2]

Dépolitisation

« faire de l’information ouverte par défaut est devenu une telle évidence culturelle aujourd’hui que les développeurs ne s’imaginent plus faire les choses autrement – un contexte bien différent de celui des rebelles politisés du logiciel libre des années 1980. »[^2]

Ainsi, il n’est plus question de défendre un idéal de liberté technique quand tout semble aller pour le mieux concernant la libre circulation du code, de l’informatique. Les développeurs ne prennent parfois plus le temps d’appliquer une licence à leur logiciel ; le code est en ligne et prendra qui voudra.

[^1]: Richard Stallman, En quoi l’open source perd de vue l’éthique du logiciel libre [^2]: Nadia Eghbal, Sur quoi reposent nos infrastructures numériques ?, 2017 [^3]: Evgeny Morozov, The Meme Hustler, 2021

lois Lehman

id : 20210118144930
dernière édition :
type : architecture
mots-clés : projet

Meir Lehman distingue[^1] trois types de logiciel. Selon leur type on leur attribue d’office certaines problématiques liées à la dette technique 🔗 et à la maintenance 🔗. Ces types sont attribués d’après deux variables :

  • les spécifications 🔗 (objectifs), les fonctionnalités attendues à la fin du développement ;
  • les solutions (moyens), les réponses techniques apportées dans le sens des spécifications.
type spécifications solutions
Statique définies définies
Pratique définies incertaines
Embarqué incertaines incertaines

Ainsi, les logiciels statiques sont développés dans une certitude complète et ne sont pas amenés à évoluer, comme un programme sur calculatrice. Les logiciels pratiques ont une finalité bien définie, évoluent peu, mais le développement est plus complexe car la solution n’est pas évidente. C’est le cas d’un jeu. Les logiciels embarqués évoluent avec leurs utilisateurs dans des situations changeantes. Ils sont à la fois complexes pour leur précision et amenés à évoluer très régulièrement, comme pour un logiciel métier.

Lois

Ce dernier type intéresse particulièrement Lehman qui lui dédie huit lois que l’on peut résumer ainsi :

  • il doit s’adapter en permanence aux changements de son environnement, sans quoi il devient moins utile : les modifications vont au gré de ses utilisateurs et de leur propre métier, mais aussi en fonction des évolutions techniques ;
  • il nécessite un effort supplémentaire et toujours plus important pour lutter contre son obésité : une complexité croissante et une multiplication permanente des fonctionnalités ;
  • il est nécessaire de conserver tout au long de la vie du logiciel la familiarité que ses utilisateurs ont entretenu avec lui en considérant que ce nombre d’utilisateur est globalement stable.

[^1]: Meir Lehman, Programs, Life Cycles, and Laws of Software Evolution, 1980

macros-définition

id : 20201106103452
dernière édition :
type : inscription

Il s’agit de définir (macro-instruction) une instructions qui pourra être répétée par substitution : Une chaîne de caractère (substitution) permet de placer une occurrence de l’instruction (définition) à laquelle est elle rattachée. Ce processus (macro-expansion) nécessite une analyse syntaxique de la saisie.

🔗 syntaxe de code

Ainsi, la saisie bjr (substitution) peut-être une macro ordonnant l’insertion de la chaîne de caractère bonjour (définition). Saisir bjr bjr rend bonjour bonjour. Il est aussi possible d’ajouter des arguments comme en écrivant bjr*3 qui donnerait bonjour bonjour bonjour.

Les définitions et leur substitution sont définies dans un dictionnaire.

Analogie avec le code

Bien que les macros n’ont pas la même utilité que les langages de programmation, on retrouve cette idée de définition et substitution avec les variables en programmation. Avec le langage Python on inscrit d’ailleurs explicitement une définition, abrégé def.

def tell_name(prenom, nom):
    print("Je suis " + prenom + " " + nom + ".")

tell_name("Guillaume", "Brioudes")

>> Je suis Guillaume Brioudes.

Utilisation

Les macros ne permettent pas de prescrire des algorithmes comme le permet un langage de programmation.

Les macros permettent de répéter d’importantes portions de code soit substituées à des chaînes de caractère comme vu précédemment, soit appelées lors de certaines commandes, par exemple une combinaison de touches. On accélère ainsi la soumissions des requêtes 🔗.

maintenance logicielle

id : 20210304181626
dernière édition :
type : processus

La maintenance fait partie intégrante du cycle de développement du logiciel 🔗. Elle permet d’assurer sa qualité 🔗. Elle débute une fois le logiciel déployé, « mis en production ». Son arrêt signifie la « mort » du logiciel. En effet, il pourra être rapidement dépassé en terme de fonctionnalité, d’environnement 🔗 (dépendance logicielle et matérielle).

« Les approches traditionnelles du processus logiciel ont mis trop l’accent sur la distinction artificielle entre développement et maintenance. L’évolution commence tôt dans le processus de développement, et la distinction entre développement et maintenance devrait être abandonnée en faveur d’un processus évolutif »[^2] (p.2)

On différencie 4 niveaux de maintenance[^1], de plus en plus lourds à effectuer :

  1. Correction d’erreurs dans le code source (et éventuellement sa documentation) ;
  2. Améliorations pour assurer de meilleurs performances, une meilleur interaction ;
  3. Adaptation à un nouvel environnement, à de nouveaux composants ;
  4. Évolution pour répondre à de nouveaux besoins.

Pour une maintenance, on effectue successivement l’analyse du problème, la spécifications 🔗 de solutions, la planification de la conception et du développement et enfin des tests.

Difficultés

Les difficultés de maintenance sur le long terme pour un logiciel sont notamment dues à une mauvaise compréhension de l’architecture du système[^2] (p.2) et à sa mauvaise documentation 🔗 de ce dernier. Il devient alors difficile de comprendre la structure du logiciel pour y dénicher l’origine du problème. Ainsi, la maintenance permet de valider l’efficacité de la documentation du logiciel sur le long terme, au fur et à mesure des version.

[^1]: Sahar Jarwah, Un modèle générique pour la gestion des informations complexes et dynamiques, 1992 [^2]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

Markdown

id : 20210829171922
dernière édition :
type : inscription

Le Markdown est un langage de balise léger 🔗 permettant (dans ses versions les plus simples) une mise en forme minimaliste de l’information. Elle peut être mise en liste, en tableau ou sous forme de paragraphes. Des portions de textes peuvent être accentuées (gras, italique) ou déclarées comme du code préformaté.

Usage

Le Markdown n’a jamais été standardisé et les internautes ont pu librement y ajouter de nouvelles normes (flavors) :

  • MultiMarkdown qui ajoute notamment les fonctionnalités suivantes : pieds de page, tableaux, légendes.
  • GitHub Flavored Markdown
  • CommonMark

Ainsi selon les interpréteurs (JavaScript, Python, PHP…) il est possible de barrer, surligner, de mettre en places des bandeaux, des liens (wikilinks 🔗), des listes de tâche, de définitions etc.. Ces langages sont dédiés à la prise de note, à la rédaction de documentation selon ses nouveaux usages.

À l’origine, le Markdown est destiné blogging, à la mise en forme de mails, de messages sur les forums… pour une transpilation 🔗 en HTML.

Il est possible en Markdown d’obtenir un même résultat avec différentes syntaxes :

Textile, AsciiDoc : _italique_ *bold*
Markdown : *italique* **bold**
Wikicréole : //italique// **gras**
BBCode : [i]italique[/i] [b]gras[/b]

Métadonnées

Certaines normes markdown proposent d’ajouter des métadonnées 🔗 aux fichiers grâce au YAML front matter. C’est une entête faite de texte contenant du code formaté selon la norme YAML. Elle est elle-même particulièrement minialiste dans sa forme.

---
title: Lorem ipseum
author: Guillaume Brioudes
date: 2021-08-29
---

matérialité d’un programme

id : 20210121192437
dernière édition :
type : processus
mots-clés : Wendy Hui Kyong Chun, Samuel Goyet

🔗 programme et programmation 🔗 software/hardware

Sur la carte mère de l’ordinateur et ses différents composants (gérés par le BIOS) sont disposés des fils. Le courant électrique passe ou non dans ces fils, équivalent à un 1 (true, un courant de 5 volts passe) ou à un 0 (false, aucun courant ne passe). C’est le binaire de l’informatique, filant presque à la vitesse de la lumière dans les circuits.

« l’altération de la matière électrique peut être lue et interprétée par une machine selon un codage précis »[^2] (p.141)

Huit fils permettent de faire passer 8 bits (0 ou 1). Sur 8 bits il est possible de transmettre des valeurs allant de 0 à 255. Avec 32 fils on arrive à un éventail de plus de 4 milliards de combinaisons.

« le matériel n’a pas besoin de logiciel pour ‹ faire quelque chose › »[^1]

Grâce à des portes logiques, il est possible de comparer les valeurs de plusieurs fils. Dans le cas d’une porte « AND », l’ensemble des fils qui y entrent doivent conduire du courant pour que la porte elle-même envoie une impulsion. C’est la logique booléenne.

« Le code source devient source [d’un fonctionnement] lorsqu’il s’intègre aux portes logiques (et à un niveau encore plus bas, aux transistors qui composent ces portes) »[^1]

« Lorsqu’une valeur change soudainement, il y a une brève période pendant laquelle une porte donnera une fausse valeur. De plus, parce que les signaux se propagent dans le temps dans l’espace, ils produisent un champ magnétique qui peut corrompre d’autres signaux à proximité »[^1]

Manipulations

Aux débuts de l’informatique, la programmation du calcul des machines dépendait entièrement des manipulations matérielles (branchement de câbles).

« il n’y a pas à proprement parler de ‹ logiciel ›. Il y a une certaine configuration matérielle de la machine, rendant sa manipulation très fastidieuse »[^2] (p.116)

Désormais, nous sommes passés du câblage à l’écriture, de la « logistique à la logique »[^2] (p.114), la seconde ayant pris le pas sur la première, reléguée au second plan (bien qu’elle reste déterminante). La documentation de code 🔗 et les modélisations 🔗 permettent de saisir la logique combinatoire 🔗, mais aussi de retrouver les métaphores matérielles d’unités, de branchement.

De la même manière, les données ont été d’abord été fixées sur du matériel (carte perforées) avant que, comme aujourd’hui (avec les ordinateurs à programme enregistré), elles ne se confondent dans le programme qui va les traiter : elles sont inscrites dans le même espace et le même encodage 🔗 (JSON + JavaScript). C’est l’idée de l’architecture de Von Neumann : « Données et instructions peuvent être représentées sous la même forme : une ligne de code où vont être indiqués à la fois quoi calculer et comment le calculer »[^2] (p.462). C’est le début des paradigmes de programmation 🔗, des réflexions sur l’agencement d’un programme sur un support.

L’abstraction 🔗, la capacité recalculatoire de l’informatique trouve sa pleine puissance quand la programmation est devenu à proprement parler un travail d’écriture (de routines, d’encapsulation des instructions 🔗) :

« C’est cette indifférenciation [de la données et des instructions de traitement] qui permet une plus grande plasticité de la machine et une programmation grandement facilitée. Il n’y a plus besoin de réarranger les câbles et autres interrupteurs de l’ordinateur. Il suffit de réécrire des instructions et/ou de lui fournir un autre jeu de données »[^2] (p.118)

[^1]: Wendy Hui Kyong Chun, On ‹Sourcery›, or Code as Fetish, 2008 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

médiation numérique

id : 20200716211301
dernière édition :
type : processus
mots-clés : Flore Barcellini, projet

Le médiateur à un rôle à la fois « épistémique et cognitif », il « traversent des frontières en transférant des informations et des pratiques »[^2] (p.57-58). Ces frontières peuvent être organisationnelles ou techniques. En les dépassant il inclut les individus dans un processus de groupe. Pour cela il traite (recherche, filtre, traduit) puis transfert des informations tout en réduisant les pertes. Le médiateur est à la fois dans l’information (le contenu) et la communication (le canal). Il est à l'aise dans les différents domaines mobilisés et c'est ainsi qu'il gagne sa légitimité et contribue à la performance d’une équipe dans l’accomplissement de ses tâches.

Selon Régis Debray, la méthode médiologique (étude des médiations techniques et institutionnelles d’un groupe humain) consiste en :

« l’établissement, cas par cas, de corrélations […] entre les activités symboliques d’un groupe humain (religion, idéologie, littérature, art), ses formes d’organisation et son mode de saisie, d’archivage et de circulation des traces »[^1]

En d’autres termes, il s’agit de transmettre un sujet à un individu en prennant en compte sa culture et les formes d’organisation du savoir que vous partager tout deux. Par ce geste il résout à la fois un problème de conception (traitement de l’information) et à la fois un problème socio-relationnel (soutient moral, résolution de conflits)[^2] (p.58).

Dispositifs

« La médiation numérique est une démarche visant à mettre en œuvre des dispositifs de flux, des dispositifs passerelles et des dispositifs ponctuels pour favoriser l’accès organisé ou fortuit, l’appropriation et la dissémination de contenus à des fins de diffusion des savoirs et des savoir-faire » Sylvère Mercier

  • dispositif de flux : dispositif stable permettant le développement d’une identité numérique pérenne, attractive et d’une habitude de lecture. Ex : un réseau social.
  • dispositif ponctuel : mise en forme d’informations de manière attractive de manière à capter l’attention des utilisateurs. Il peut s’insérer dans un dispositif de flux. Ex : un article de blog, une vidéo YouTube.
  • dispositif passerelle : milieu fait d’une réalité tangible et de données numériques pour créer un lien entre le monde numérique et le monde réel. Ex : une borne dans un musée qui donne des informations numériques.

[^1]: Régis Debray, Manifeste médiologique, 1994 [^2]: Flore Barcellini, Conception de l’artefact, conception du collectif, 2018

memex de Vannevar Bush

id : 20200622110109
dernière édition :
type : architecture
mots-clés : Anthony Masure

Intention

Vannevar Bush voulait augmenter la mémoire humaine, en taille et en pérennité. Pour ce faire il veut reprendre le modèle de l'encyclopédie, mais lui ajouter un mode interactif et asynchrone : Il a étudié le cheminement de l'information, de la pensée, comme il le présente dans son essaie As We May Think (1945)[^2] dans lequel il théorise le Memex, sa « fiction technique »[^4].

« [The human mind] operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain. » « Man cannot hope fully to duplicate this mental process artificially, but he certainly ought to be able to learn from it. »[^1]

Il veut essayer de reproduire un circuit intuitif pour consulter, annoter et partager des documents de manière fluide et pour ce faire être assisté par une machine. Ainsi le Memex (MEMory EXtender) est une interface de consultation d'une base de données documentaire (stockée sur des bandes magnétiques).

« Yet specialization becomes increasingly necessary for progress, and the effort to bridge between disciplines is correspondingly superficial. »[^1]

Il entreprend cette création en voyant ses pairs nécessairement s'enfoncer dans les strates de la spécialisation, compliquant la communication entre les différentes branches. Le Memex permettrait d'échanger plus facilement en partageant des encyclopédies conçues à partir d'une masse documentaire écrémée, annotée et reliée. De plus, le parcours de cette encyclopédie est aidé par des outils permettant de passer les pages à grande vitesse, de se rendre à un point précis de la base grâce à une interface mécanique simple.

On parle d'un proto-hypertexte, d'un prototype établissant les principes de l'hypertexte d'après les écris de Paul Otlet comme Vannevar Bush dit s'être inspiré.

Fonctionnement

On considère le Memex de Vannevar Bush comme l'un des premiers appareil hypertexte. C'est un meuble (« ordinary desk ») avec différents équipements permettant de lire et annoter différents documents stockés sur des bandes magnétiques. Les documents (ensembles de pages) s'affichent sur un écran écrans et des manettes permettent de passer d'une page à une autre plus ou moins rapidement : « If he deflects it further to the right, he steps through the book 10 pages at a time; still further at 100 pages at a time. »[^1].

Le second écran peut également être sollicité pour pouvoir consulter une autre page, comme complément d'étude de la première : « As he has several projection positions, he can leave one item in position while he calls up another »[^1]. L'utilisateur peut même décider de faire une liaison entre les deux.

Chaque page possède un identifiant unique qui y est annoté. Le meuble affiche également l'identifiant de la page active. Un clavier permet de saisir un identifiant et un bouton de lancer l'affichage de la page correspondante à l'identifiant entré : « If the user wishes to consult a certain book, he taps its code on the keyboard, and the title page of the book promptly appears before him »[^1].

Un stylet permet d'annoter le document sur l'un des deux écrans, voire d'en créer un : une platine (« transparent platen ») est disposées sur le bureau et permet de « photographier » un document, une saisie manuscrite (« memoranda »), pour l'enregistrer sur la bobine.

Utilisation

Dans son essaie As We May Think (1945), Vannevar Bush imagine des professionnels (un avocat, un médecin, un historien… ) revenir sur leurs anciens écris ou ceux de leurs pairs. Il imagine une enquête sur les arcs ou un chercheur exécuterai successivement les taches suivantes :

  1. Il trouve une problématique
  2. Il lit ce qu'il a déjà dans son Memex, lit d'autres sources et il relie (link) les plus pertinentes dans l'arborescence de son Memex tandis qu'il annote et forme ainsi une piste (« building a trail », enregistré pendant l'utilisation sur la bande magnétique), bifurque sur une autre (« he branches off on a side »)
  3. Il partage son travail

Photographie

Le Memex est principalement basé sur la photographie au sens de support photosensible : sensible aux rayonnements lumineux. C'est ce procédé qui va permettre d'imprimer les documents sur les bandes microfilm (support de stockage analogique), mais aussi d'y apporter des notes avec le stylet. Ainsi le Memex profite des dernières techniques analogiques en matière de prise de vue « à la volée ».

Le Memex restera toujours, résolument, une machine analogique.

🔗 opposition numérique/analogique 🔗 notion de paradigme

Partage

Plus tard il se rend compte qu'il a besoin de ces travaux pour un pair : il photographie tout le parcours (« photographs the whole trail out ») et lui partage pour l'insérer dans son propre Memex.

La base est stockée sur une bobine, plus facilement reproductible, consultable et mois chère qu'un corpus de centaines de pages.

Construire ainsi des encyclopédies et les partager est plus efficace que de mettre en place une grande bibliothèque où l'on « trouverait tout » pour concrètement voir une minorité miner l'information plutôt que de la trouver.

« Even the modern great library is not generally consulted; it is nibbled at by a few. »[^1]

Liaison

Le Memex en tant que prototype ne permet pas d'intégrer des liens aux pages, mais de programmer leur succession (par signets, « associative indexing »). Ainsi, ne peut succéder à une page qu'une seule autre page, définie à l'avance: « It is exactly as though the physical items had been gathered together from widely separated sources and bound together to form a new book »[^1]. Ces liens hypertextes ne sont pas « cardinaux », multi-directionnels.

Pourtant la théorie du Memex va au-delà de cette limite : Vannevar Bush imagine une structure interne des pages dans un format qu'il n'est pas celui du document original, mais une version adaptée pour son outil et qui serait conçu suite au scan d'un document.

Hypertexte

Selon Alexandre Serres[^3], on peut prêter les caractéristiques hypertextes suivantes au Memex :

  • lecture et écriture non linéaires : navigation et annotation personnalisées
  • découpage de l’information en unités préindexées grâce à des identifiants uniques et inscrits dans les pages
  • multifenêtrage permettant de consulter et compare les documents

Vers le web

Le Memex est le premier outil permettant d'actionner une logique documentaire précurseur de ce qu'est le web et cela selon différents aspects :

  • Chaque document, chaque page est identifié permettant de mettre en place les liaisons
  • Il est possible de lire et écrire sur les pages (comme Tim Berners-Lee imaginera l'utilisation des pages web)
  • On peut créer un documents et le stocker dans la base
  • La base documentaire peut être partagée (physiquement, en donnant a bobine)

Sources

https://www.youtube.com/watch?v=q8s2jkq-R5o https://www.youtube.com/watch?v=c539cK58ees https://en.wikipedia.org/wiki/Memex https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/

[^1]: Vannevar Bush, As We May Think, 1945 [^2]: Selon Alexandre Serres dans Hypertexte : une histoire à revisiter (2015), les recherches de Vannevar Bush sur le Memex et la rédaction de son article auraient commencé dès 1932 [^3]: Alexandre Serres, Hypertexte : une histoire à revisiter, 2015 [^4]: Anthony Masure, Le design des programmes, 2014

message d’erreur

id : 20210701175229
dernière édition :
type : documentation

Les messages d’erreur sont en général de courtes explications d’un problème survenu suite à une action de l’utilisateur interceptée bloquée par les développeurs. En effet, un message d’erreur est programmé, ce qui implique qu’il peut être oublié ou lui-même sujet à un dysfonctionnement.

« De bons messages d’erreur ne sont pas seulement un problème d’interface utilisateur, mais il s’agit d’un problème de conception logicielle »[^1] (p.333)

Documentation

Le message d’erreur a pour objectif de stopper l’action, d’expliquer ce qu’il se passe et de proposer une solution ou une alternative. Celle-ci peut ne pas tenir dans la boîte de dialogue. En plus d’une courte introduction, elle peut annoncer un identifiant, code d’erreur, ou même un lien directe. Lequel pourra rediriger la personne vers le mode d’emploi 🔗, plus riche en explications et alternatives. Cela permet à l’utilisateur de profiter à la fois du contexte d’utilisation menant à l’erreur et d’un réseau d’information à son sujet.

Il faut rester courtois, positif et juste vis-à-vis de l’utilisateur, ça n’est jamais sa faute s’il y a une erreur. Il mérite de la pédagogie ; il faut éviter le jargon et les formules imprécises, hésitantes. Ça n’est pas à l’utilisateur de deviner les causes d’une erreur ; le programme peut aisément les déterminer (notamment par la gestion des exceptions, comme dans l’extrait de code ci-après).

Historique

Il est important qu’un utilisateur puisse retrouver une erreur rencontrée pour pouvoir y revenir. On peut lui proposer un historique d’un ou plusieurs éléments, ainsi que des actions qu’il a effectué. Il pourra ainsi savoir quelles actions ont abouties et lesquelles ont pu mener à une erreur.

Les erreurs peuvent être indexées dans un journal d’erreur (log file), soit une liste, soit un fichier .log. C’est un document technique qui ne convient qu’aux utilisateurs expérimentés et où l’on peut présenter pour chaque erreur

  • la gravité (différencier un dysfonctionnement d’une d’une panne, d’un crash)
  • l’horodatage (à la seconde près, time-stamp)
  • l’objet (la fonctionnalité qui n’a pas pu aboutir)
  • la solution (réglage, contact du support…)
  • la cause (les matériaux du programme qui ont dysfonctionné, la configuration 🔗 actuelle)
  • les conséquences

Ce dernier point intéresse principalement les développeurs qui dépendent souvent de messages d’erreur une fois lancés dans l’édition du code. Ils peuvent être interessés par la présentation de la chaîne complète d’erreur pour évaluer sa propagation.

function sayYes (answer) {
    if (aws !=='yes') {
    throw'You were supposed to say "yes"!' }
}
sayYes('no');

/**
You were supposed to say "yes"!
Thrown at:
    at sayYes (D:\dev\cosma\test.js:5:9)
    at D:\dev\cosma\test.js:9:1

Rédaction

Les messages d’erreur inscrits dans des boîtes de dialogue doivent être plus courts et présenter brievement ces informations, quitte à créer un panneau déroulant « Afficher les détails ». La liste d’informations précédente permet de vérifier que l’on a bien donné toutes les informations utiles. Une icône pourra indiquer la gravité tandis que l’exposition de l’erreur, ses causes, conséquences et solutions doivent tenir sur quelques lignes.

Sécurité

Attention à ne pas délivrer d’informations sensibles sur le système dans les messages d’erreur. Donner la cause d’une erreur peut mettre en danger le système en informant un utilisateur malveillant de son fonctionnement. Par exemple, pour une erreur d’authenficiation (identifiant et mot de passe), il ne faut pas renvoyer « Mot de passe incorrecte » ou « Identifiant incorrecte », mais plutôt « Mot de passe ou identifiant incorrect ». Les deux premières formules suggèrent que l’identifiant ou le mot de passe sont effectivement attachés à un utilisateur et qu’il ne reste plus aux forceurs qu’à trouver la seconde information.

Dans la même logique, on ne relaye jamais un message d’erreur permettant d’identifier une technologie. Relayer un message d’erreur typique de MySQL signale à un utilisateur malveillant les failles exploitables.

[^1]: Microsoft, Guide d’expérience utilisateur

métadonnées

id : 20200923152146
dernière édition :
type : inscription
mots-clés : Bruno Bachimont, technique

Les métadonnées sont des « données permettant à un système de manipuler d’autres données »[^1]. Sans intégrer le contenu, elles permettent de singulariser et d’apporter des précision sur un objet. Le titre d’un livre n’est pas juste une information de description de l’objet, mais aussi un moyen de retrouver l’ouvrage dans une base documentaire.

Pour un objet on peut enregistrer des métadonnées de différents types pour autant d’usages :

  • descriptives (Dublin Core : titre, date, droits…)
  • administratives (identifiant, date de modification, de suppression…)
  • structure (type de données, nombre d’octets…)

Micro-données

Le Dublin Core est un schéma de micro-données, une ontologie 🔗 de 15 métadonnées permettant de caractériser tout document. Elles sont relatives

  • au contenu (titre, sujet, description, source, langue, relation, couverture) ;
  • à la propriété intellectuelle (créateur, contributeurs, éditeur, gestion des droits) ;
  • à la génération (date, type, format, identifiant).

On peut également citer ces autres schémas :

  • Open Graph (Facebook)
  • Schema.org (Bing, Google, Yahoo! et Yandex)

Ils permettent d’enregistrer du contenu sémantique au sein des pages web comme avec les balises présentées ci-dessous. On indique successivement le titre de la page web selon les schémas Dublin Core, Open Graph et Twitter

<meta name="DC.Title" content="…">
<meta property="og:title" content="…">
<meta name="twitter:title" content="…">

[^1]: Bruno Bachimont, Ingénierie des connaissances et des contenus, 2007

méthode des projets agiles

id : 20200505212332
dernière édition :
type : processus
mots-clés : projet

Les projets agiles répondent à une difficulté inhérente aux projets innovants : rassembler des personnes de différents métiers pour proposer une solution en réponse à un besoin évolutif. Ces méthodes ne sont pas adaptées à tous les projets et certaines sont plus lourdes que d‘autres à mettre en place. Un·e master est présent·e dans l‘équipe pour s‘assurer que les principes suivants sont appliqués.

Les principes suivants découlent de la méthodologie Scrum, mais il est possible d‘alléger ces principes pour aller avec une GPS : Gestion de Projet Simple.

Découper le besoin

L‘expression du besoin innovant évolue au fur et à mesure du projet. Tel qu‘il est exprimé par la personne en demande, nous parlons d‘un besoin primaire. Cette notion va être travaillée durant le « sprint 0 » dans différents documents, notamment un cahier des charges (objectif, délais et coûts) pour devenir un besoin fonctionnel, auquel on est désormais en mesure de répondre techniquement, par une cascade de tâches.

![schema methode projet agile scrum](./images fiches/schema methode projet agile scrum.png)

Itérations

Cette cascade de tâches va être amenée à évoluer : le besoin va se préciser, les difficultés vont orienter les choix techniques. Le projet innovant est agile par nécessité. Œuvrer nécessite toutefois une certaine stabilité. Ainsi on va enchaîner en équipe les phases d‘analyse et de réalisation. Pour veiller à ce que que le tout corresponde au besoin évolutif, on ajoutera une phase d‘évaluation de la réponse technique.

  1. Analyse
  2. Réalisation
  3. Évaluation (si elle est concluante par rapport à ce qui a été demandé après analyse, on passe on retourne à l‘étape 1, sinon à l‘étape 2)

Ces trois phases vont former un sprint, une période limitée débutant par un brief, une mise au point sur ce qui va être réalisé par les membres de l‘équipe durant le semaine, la quinzaine, le mois. On va itérer les sprints jusqu‘à avoir complété et validé toutes les tâches de la cascade. Toutes les modalités de travail sont définies lors du « sprint 0 ».

User stories

Dans l‘équipe est nommé·e un·e product owner, responsable de la conception des user stories. Ce sont des blocs de fonctionnalité qui répondent à un même besoin utilisateur. Les user stories seront plus tard découpées en tâches dès lors qu‘elles sont valides : elles doivent

  • être indépendantes
  • être négociables en terme de « coût »
  • être interchangeables ;
  • apporter une valeur ajoutée au projet ;
  • être estimables en temps et argent
  • avoir une taille appropriée

Chaque user story valide entre dans le backlog de l‘équipe, la liste d‘attente.

Créer la situation

Pour les méthodes agiles, on va privilégier des situations plutôt que des dispositifs inertes :

  • individus et interaction, plutôt que processus et outils ;
  • fonctionnalités opérationnelles, plutôt que documentation exhaustive ;
  • collaboration avec le client, plutôt que contractualisation des relations ;
  • acceptation du changement, plutôt que conformité aux plans.

L‘un des grands outils de la méthode agile est le mur blanc couvert de post-it, chacun représentant une tâche. Ainsi des informations minimales peuvent êtres (dé)placées formant un système concret pour appréhender son équivalent abstrait. La version électronique de ce dispositif est bien moins prisée.

En effet, cet agencement créer des situation : avoir terminé une tâche signifie pouvoir venir à ce mur et déplacer un post-it. Les gens quittent leur écran et se lèvent, vont vers le tableau, s‘y réunissent.

Le mur couvert de post-it disposés sous forme de colonnes selon la typologie suivante :

  • backlog : n‘a pas encore été planifié ;
  • sprint x : a faire dans le sprint actuel ;
  • in progress : en cours de réalisation ;
  • testing : en cours de test. S‘il y a un bug, retour à la colonne in progress ;
  • done : tâches terminées. On n‘en retire pas les post-it, c‘est plaisant de voir le projet avancer.

Réunions

Au départ de chaque sprint, on planifie : les ouvriers et le·a Product owner échangent autour des user stories. C’est le moment de préciser concrètement les besoins et de parler technique. Les ouvriers vont donner des points (« coût ») à chaque user stories en fonction de la complexité de réalisation qu‘ils estiment. C‘est le poker planning En effet, chaque sprint a un « coût » maximum que l‘équipe peut encaisser en collaboration. Si une user story obtient un coût trop important, c‘est qu‘elle n‘a pas bien été définie : elle doit être scindée. Si des ouvriers donnent un « coût » très différent pour une même user story, c‘est qu‘elle n‘a pas bien été comprise. Ce nombre peut évoluer, au fur et à mesure du projet. Il vise à limiter les tâches réalisées, mieux réalisé quand il n‘est pas exécuté sous pression.

Une fois que ces « coûts » ont été définis, tout le monde se lance dans le travail sans revenir en arrière pour planifier. Les retours sur les user stories se feront au début du print suivant.

Tous les jours, l‘équipe va procéder à une « mêlée » de 15 minutes : une réunion où tout le monde va présenter les tâches sur lesquelles il a avancé depuis la derrière « mêlée » et comment cela s‘est déroulé. Tout le monde sait où en est tout le monde.

En fin de sprint on fait une revue de ce qui a été produit. C’est le moment des commentaires, suggestions qui sont potentiellement placées dans le tableau, en backlog. Avec cette méthode, on a le droit à l’erreur et il y a de la remise en question permanente en équipe : ce n’est jamais l’erreur d’un seul, ni du système, mais de l‘équipe.

Réalisation

La réalisation varie selon l‘avancée du projet. Les premières réalisations sont des prototypes tandis que les dernières s‘approchent d‘un produit fini. De même l‘évaluation peut prendre la forme d‘un test, d‘une révision en fonction de la réalisation. L‘évaluation entre pairs est un principe clé de la méthode de projet agile.

🔗 git flow, programmation agile

métier d’éditeur

id : 20200607195524
dernière édition :
type : processus
mots-clés : Marcello V.R.

Il est le « professionnel de la chose éditoriale » est compétent dans le « savoir éditer ». Il est à la fois « homme de lettres et entrepreneur ». Un éditeur a une double responsabilité matérielle et morale vis à vis d’une œuvre, comme une « contre-signature » perpétuelle dans son métier. Il est à la fois

  • editor : « consacre et qui dirige la publication d’ouvrages », développement du manuscrit, conception de la maquette dans un travail plus technique
  • publisher : « responsabilités de gestionnaire et d’administrateur propres aux conditions de production et de diffusion des ouvrages »

Figure symbolique de l’éditeur

Sa fonction lui confère aussi une légitimité symbolique dans le champ littéraire et plus généralement culturelle. Il jouit tout comme l’objet livre d’un statut particulier qui lui donne le pouvoir de « consacrer » des auteurs et a fortiori des écrivains : on lui reconnaît « le mérite de la révélation et le privilège de la propriété ».

Pour un éditeur, choisir un auteur, publier un livre c’est se constituer une image de marque, « une identité singulières ». Son catalogue est une vitrine, pour les auteurs, mais aussi pour le public entre lesquels il se place comme médiateur, toujours dans son antagonisme d’« homme de lettres et entrepreneur ».

Processus d’édition

Une œuvre peut être soumise (l’auteur propose son manuscrit) ou bien commandée (la maison d’édition a demandé à un auteur de lui concevoir une œuvre, librement ou non).

  1. Choix des manuscrits

Le manuscrit est l’œuvre, plus ou moins brute, telle qu’elle a été produite par l’auteur. C’est ce document que va consulter l’éditeur ou bien qu’il va confier à un lecteur externe, voire un comité de lecture dans les maisons d’édition de grande taille.

Le choix va s’opérer selon une ligne ou politique éditoriale avec pour ultime juge l’éditeur qui va étudier les critères de sa collection, de son catalogue.

  1. Élaboration et mise en forme

L’auteur va être accompagné dans l’« élaboration et la rédaction finale de son ouvrage ». L’éditeur peut déléguer ce travail à un directeur de collection ou à un directeur littéraire. La collaboration débute entre les deux partis. Dans les grandes maisons d’édition, l’éditeur doit travailler avec des responsables financiers et dans tous les cas établir avec l’auteur le « tirage » envisagé dans un contrat de cession des droits d’auteurs précisant les devoir des deux partis.

Ensuite on corrige, on traduit en faisait appel à des agents externes. La coordination de ces nombreuses personnes dépend de l’éditeur ou bien souvent d’un secrétaire d’édition.

  1. Fabrication

L’éditeur donne son imprimatur.

De nombreuses personnes vont encore intervenir sur le livre dans une démarche à la fois artistique et technique. Avant de réaliser les « épreuves de l’ouvrage », il faut mettre en page, « déterminer la taille et le type de caractères retenus, superviser la reproduction et l’insertion des illustrations […] calibrer la maquette du livre, en estimer le nombre de pages ».

« Sans chercher à surestimer l’importance de la valeur esthétique d’un livre, sa présentation matérielle (qualité de l’impression, choix des papiers et cartons), sa signature graphique (élégance, recherche du design, esthétique générale) sont pourtant eux aussi responsables de la signature et de l’image (de marque) de la maison d’édition »

  1. Diffusion et distribution

« En apposant son nom ou celui de sa maison d’édition au bas d’un livre, un éditeur s’engage de facto dans l’espace public », mais il engage également les « valeurs littéraires », celles d’un mouvement artistique, d’un courant de pensée. C’est un rôle social, politique qui a grande échelle assure « le développement et la pérennité de la vie intellectuelle ».

Enjeux du numérique

Le numérique vient bouleverser l’institution de l’édition. Toutefois les éditeurs ont la possibilité d’exercer leur rôle, plus important que jamais. Quand de toutes parts on écrit et on publie dans l’espace public (réseau mondial), quand on pourrait croire que l’on peut se passer d’eux, les éditeurs gardent tout de même leur autorité artistique et intellectuelle et par conséquent leur rôle de médiateur.

« du livre papier à son pendant dématérialisé, s’impose encore et toujours la nécessité d’un intermédiaire entre l’auteur et le lecteur » ; « les lecteurs de demain auront besoin de certifications, de labels, de garanties de qualité. Les éditeurs leur apporteront cette caution »

Source : EBERLE-SINATRA, Michael et VITALI ROSATI, Marcello (éd.), 2014. Pratiques de l’édition numérique [en ligne]. Parcours numériques. Montréal : Les Presses de l’Université de Montréal. [Consulté le 7 juin 2020]. Parcours numériques. ISBN 978-2-7606-3202-8. Disponible à l’adresse : http://parcoursnumeriques-pum.ca/introduction-20

minifier le code

id : 20210218193747
dernière édition :
type : inscription

La minification de code source est une opération souvent automatisée par un outil de développement 🔗. Elle consiste à appliquer plusieurs opérations (combinables) à un code source :

  • supprimant les espaces, tabulations (peuvent facilement être retrouvés avec un logiciel de beautify) ;
  • supprimer les commentaires ;
  • factoriser toutes les opérations et conditionnelles ;
  • renommer les fonctions et variables avec un minium de caractères.

Cela a souvent pour effet de rendre les fichiers sortants difficilement compréhensibles, voire illisibles par les humains. C’est du « code au kilomètre », inscrit à un niveau techno-sémiotique (il signifie uniquement en vue de fonctionner et non d’être lu).

On voit ci-dessous que l’on perd toute notion de sémantique (le nom isWide et le paramètre number explicitaient respectivement l’utilité de la fonction et le type de données requis) et d’espace (le marquage de la conditionnel). Aussi, le soin apporté à l’inscription du code 🔗 (indentation, espacement) est balayé.

function isWide(number) {
    if (number >= 1000) {
        return true;
    }
    return false;
}
// minify :
function f(e){return e>=1e3}

Utilité

  • Perte de poids : les fichiers étant réduits à une taille minimum, ils sont plus rapides à télécharger pour les clients 🔗 et à interpréter 🔗. Il est possible de réduire de 15% à 70% le poids.
  • Rendre le code impénétrable : que ce soit pour éviter la rétro-ingénierie, la concurrence ou simplement pour cacher les particularité de son code, un développeur peut décider d’en effacer le sens.

mode d’emploi

id : 20210213103719
dernière édition :
type : documentation

🔗 médiation numérique

Le mode d’emploi est une documentation permettant de « décrire un objet technique de manière à rendre intelligible son mode de fonctionnement et l’interaction qu’il suppose avec un utilisateur »[^1]. Il est adressé au grand public (cible très générale) pour leur faire acquérir des compétences techniques spécifiques (réponse à un problème, nouvelle compétence avec l’outil…) et non pour comprendre le fonctionnement de l’objet.

« La plupart des logiciels sont exécutés par des utilisateurs confus agissant sur la base d'informations incorrectes et incomplètes, faisant des choses auxquelles le concepteur ne s'attendait pas »[^4] (p.53)

Le médiateur, narrateur du mode d’emploi s’incarne comme le concepteur de l’objet technique. Il est celui qui a compris l’objet technique dans toute sa complexité matérielle et procédurale (temporel). Or, ça n’est pas d’un technicien dont nous avons besoin pour écrire le mode d’emploi, mais d’un narrateur :

« Passer de la manœuvre (observée ou éprouvée) au mode d’emploi, c’est passer de la chronologie des opérations à la chronologie propre au récit »[^1]

La narration du mode d’emploi est la mise en situation de l’utilisateur.

On se demandera lors de sa rédaction comment établir un rapport sain avec le lecteur (de fait mis en position d’incapacité) et comment traduire clairement un processus, passer du texte au geste.

La conception de l’objet technique va former le mode d’emploi, va prescrire une narration. Faciliter l’usage de l’objet c’est préparer un mode d’emploi plus accessible, c’est minimiser l’apprentissage nécessaire pour l’utilisation de l’objet technique.

Temps d’utilisation

« l’initiation, le perfectionnement, l’aide-mémoire, le dépannage sont autant d’usages différents du mode d’emploi »[^1]

Le mode d’emploi va pouvoir être consulté en différents temps. Beaucoup d’utilisateurs s’estiment déjà formés et capables en autonomie. Ils ne vont donc pas le lire. « Le corollaire de ce phénomène est que si les utilisateurs veulent lire le manuel, ils sont probablement en proie à une sorte de panique et ont besoin d’une aide immédiate »[^3] (p.149). Des utilisateurs ne vont le lire le mode d’emploi que pour dépannage, quand l’interface de la machine n’est plus capable de le guider seule. Les connaissances de l’utilisateur vont également varier au contact de l’objet technique référence. Pour répondre à cette diversité des usages, il nous fait un mode d’emploi modulaire. Différents parties nommées dans le sommaire vont être adaptées à un usage précis.

Dépannage

Dans la partie dédiée au dépannage on va paradoxalement faire appel aux connaissances techniques de l’utilisateur. En parallèle d’explications techniques exhaustives, on va laisser l’utilisateur pallier ses propres spécificités. On pourra également le renvoyer vers d’autres aides.

Lors du dépannage, tous les utilisateurs ne partent pas du même point, ou peuvent être interrompus dans leur démarche. Certains vont reprendre la démarche de mise en route depuis le début ne sachant pas à quel point de la chaîne temporelle du fonctionnement de l’appareil ils se trouvent. D’autres vont se situer et tenter de retrouver leur jalon dans les consignes de dépannage. Il est donc important de représenter cette chaîne temporelle et les démarches possibles depuis chacune.

Programmation de l’action

« le mode d’emploi se définit en particulier par le fait qu’il suppose un temps d’utilisation qui soit distinct du temps d’utilisation du dispositif lui-même »[^1]

Lorsqu’un utilisateur lit un mode d’emploi, on veut contrôler son action. S’il doit lire (pour comprendre) un certain nombre d’étapes avant d’agir, il faut le manipuler à cette fin. On peut aussi installer une ambiance d’apprentissage : « Il vous faut une journée concentrée pour apprendre à utiliser cet outil. C’est complexe, mais on va vous aider. Si vous avez une difficulté, cliquez ici ».

« il faut même, dans certains styles didactiques, s’employer à le faire taire et à l’empêcher d’agir »[^1]

Le médiateur, narrateur du mode d’emploi (qui incarne le concepteur de l’objet technique), doit aussi s’effacer dans la transmission de sa compétence pour que l’utilisateur (qui devient capable) puisse se l’approprier.

« Le fantasme de maîtrise de la transmission, de modelage parfait et contrôlé de l’enfant ou de l’apprenti doit être toujours déçu sous peine de conduire éducateur et éduqué dans une relation pathologique »[^1]

Le médiateur, narrateur est aveugle, « ne sait rien à coup sûr des effets du processus de transmission »[^1]. Il ne peut juger du transfert de ses compétences. Ce transfert est l’équivalent d’une traduction (subjective, imparfaite) plus que d’une transposition (symétrique, aboutie). Les consignes laissées à l’utilisateur laissent de l’inadéquation et du malentendu[^1].

On fait confiance à la capacité de réinterprétation de l’utilisateur.

« Dire la technique, c’est passer d’une structuration technique du monde à une structuration linguistique, deux médiations qui ne sont jamais équivalentes »[^1]

Empathie

Un guidage absolu ne mène pas nécessairement à une bonne traduction, un bon « rapport didactique »[^1]. Notre vocabulaire de transmission est hérité d’autres personnes. On ne s’adresse pas par notre mode d’emploi à nos cousins, mais à un autre mode de compréhension. Il faut donc traduire largement.

« Assurer la transmission, c’est aussi anticiper la trahison probable de ces positions, le refus par l’utilisateur de les tenir »[^1]

Les utilisateurs ont souvent hâte de se jeter dans l’action. Ils décident de se lancer jusqu’à rencontrer un problème et apprennent alors de leurs erreurs via la documentation (qui arrive tardivement dans le processus).

Il faut anticiper une diversité sociale des usages, des littératies, une variabilité du temps dédié à la formation à l’outil et à son usage. On cherche à mettre en scène un usage. On est alors tenté de proposer une diversité des narrations, des expressions pour éviter un dispositif trop particulier. Il est nécessaire de faire attention à l’écriture technique 🔗 employée.

« Il faut parvenir à produire un supposé utilisateur universel à travers cette réduction dans la mesure où chaque situation ne peut être traitée de façon particulière »[^1]

Il va falloir durant la présentation de l’objet faire comprendre un certain nombre de concepts à l’utilisateur. Jim Fisher[^2] évoque un exemple avec l’installateur de logiciel de MacOs, les fichiers .dmg. Lorsqu’on les ouvre, une fenêtre apparaît avec d’une part l’icône de l’application que l’on souhaite installer et d’autre part l’icône du répertoire des applications. Si on double-clique sur l’une des deux icônes, on ouvre respectivement le logiciel et le répertoire des applications, mais sans jamais installer le logiciel. L’action à réaliser : saisir la première icône pour la lâcher par-dessus la seconde. Les développeurs affichent souvent une flèche « drag and drop » entre les deux.

Ça n’est pas une action simple, elle repose sur des concepts : le fichier .dmg n’est pas le programme, mais l’installateur ; installer un programme sur MacOs veut dire l’importer dans le répertoire des applications. Aucune action n’est simple et il y aura toujours des gens avec un savoir-faire autre qui pourront se retrouver bloquer face à une explication. Il faut donc varier et ne jamais mettre l’utilisateur en tord. Ainsi, l’indication « drag to install » semble bien plus efficace. Il faut interroger, décrire la complexité 🔗 d’un objet pour pouvoir l’expliquer.

« l’utilisateur doit pouvoir vérifier qu’il a compris les instructions et qu’il les a exécutées correctement […] la documentation doit également mentionner comment l'utilisateur peut vérifier si l'opération a été un succès ou un échec »[^3] (p.153)

Combinaison d’informations

Le plus efficace pour faire comprendre l’utilisation à une personne est de déliver une série d’explications cohérentes, claire et concises, pour mettre en place un système combinatoire 🔗 d’informations. L’utilisateur va pouvoir les appliquer, les mettre en relation (croiser deux proposition pour obtenir sa solution, bifurquer dans sa lecture). On réduit ainsi la quantité d’information tout en ouvrant les possibles. Cela commence dès la conception de l’outil, pour faire de l’interface sa propore documentation 🔗 et le point de départ logique pour l’utilisateur vers sa documentation intérmédiaire.

Si les consignes d’utilisation ne sont pas cohérentes entre elles « l’utilisateur doit apprendre chaque exception séparément »[^5] (p.33).

Verbalisation

On se demandera comment utiliser les bons « marqueurs linguistiques »[^1] pour instaurer une relation didactique, un rapport social unidirectionnel, sans interaction autre que la lecture. L’utilisateur prend quant à lui des décisions unilatérales.

Le discours exposé à l’utilisateur par le narrateur doit être sur ton de l’« assistant plein d’esprit »[^5] (p.46), ni soumis, ni condescendant.

Écrire « le moteur s’arrête quand le manche est placé à la verticale » revient à « annuler rhétoriquement le travail de l’utilisateur, qui reste pourtant indispensable »[^1].

Madeleine Akrich et Dominique Boullier[^1] dressent une liste de positions (ton) concepteur-utilisateur :

  • concepteur abstrait : « Mettre le coffret sous tension », avec un vocabulaire neutre et convenu dans les notices d’un domaine ;
  • concepteur accompagnant : « Mettons sous tension le coffret », on met en scène un rapport de direction du concepteur vers l’utilisateur, mais en le décrivant comme un geste à deux pour l’adoucir ;
  • concepteur directeur : « Mettez le coffret sous tension », pour une relation franche prescriptive et impérative ;
  • concepteur met en garde : on interdit des usages pour prévenir une erreur, voire un danger.

« Ces choix rhétoriques se combinent dans un même mode d’emploi, mais dans une proportion limitée : on construit un rapport social en l’inscrivant dans ces styles, et le modèle adopté contraint durablement l’exposition »[^1]

Ils mettent en évidence trois biais dans la rédaction des mode d’emploi :

  • Éviter les difficultés de la narration en utilisant un vocabulaire trop technique.
  • Parier sur la représentation logique par l’utilisateur de l’objet technique.
  • Narrer un espace de manœuvre, représenté par le langage, avec un lecteur engagé dans une panoplie de solutions.

Il ne faut pas confondre ce que l’on est capable d’en dire avec la réalité de l’objet technique. Ce sont deux mondes différents.

« Décrire la transmission des techniques, c’est toujours risquer de la ramener à la description des médiations que l’on a pour la décrire, à savoir le langage »[^1]

Distances

« ces relations [entre un objet et son utilisateur] ne peuvent pas être uniquement décrites sur le registre de la manipulation. Cela est particulièrement sensible dans le cas d’un certain nombre de technologies modernes pour lesquelles le lien entre le geste et le résultat escompté est assez faible, ce qui est dû à l’allongement de la chaîne des intermédiaires auxquels est déléguée la réalisation du programme d’action »[^1]

Les objets techniques numériques instaurent de fait une large distance avec leurs utilisateurs. Ils définissent un « scénario d’interaction »[^1] dans lequel l’utilisateur ne peut intervenir.

L’objet technique est lui-même pris dans un système, en interaction avec d’autres objets techniques. Il est dans un contrôle relatif d’un scénario dont il est un maillon, voire le déclencheur, mais que l’utilisateur n’a pas la capacité de contrôler à travers lui.

🔗 dépendances logicielles

« au travers d’un même objet, plusieurs états ou ‹ postures › de l’utilisateur sont gérés simultanément »[^1]

Hypertexte

L’expérience de l’utilisateur varie selon le support du mode d’emploi. La version matérielle peut être perdue par l’utilisateur. C’est d’autant plus probable qu’il ne le consulte que rarement et décidera peut-être de ne pas le conserver. La version en ligne nécessite de posséder du matériel et des compétences en littératie numérique 🔗 qui nécessite une approche très pointue de l’expérience d’utilisation. Elle permet aussi, de profiter des avantages de l’hypertexte 🔗 d’annoter la documentation 🔗.

La documentation peut aussi être intégrée directement au matériel d’utilisation comme pour une documentation intégrée à l’interface du logiciel 🔗.

[^1]: Madeleine Akrich et Dominique Boullier, Le mode d’emploi : genèse, forme et usage, 1996 [^2]: Jim Fisher, Don’t Say Simply, 2018 [^3]: Jakob Nielsen, Usability Engineering, 1993 [^4]: Paul Heckel The Elements of Friendly Software Design, 1984 [^5]: Wiliam Horton, Designing & writting online documentation, 1990

modèle, pattern

id : 20200526222401
dernière édition :
type : architecture

Un modèle (pattern) forme l’axe de symétrie entre sa composition et son instance 🔗. Il s’agit d’isoler les qualités et usages d’objets ou concepts, à travers un prisme de conception. On cherche ainsi à simplifier (« Supprimer ce qui n'est pas essentiel »[^1]) une entité ultra-complète pour l’intégrer à un système fini et commensurable (au sein duquel les modèles peuvent être comparés avec une unité de mesure commune).

Un modèle est une abstraction 🔗, il représente une réalité, mais ne constitue pas cette réalité ; il ne ressemble pas à cette réalité mais est adapté à l’utilisation souhaitée : pour une même réalité il peut exister plusieurs modèles

On admet des biais, nécessaires pour pouvoir extrapoler (faire hériter de) ce modèle et l’appliquer à différentes instances. On facilite ainsi la compréhension d’une série de réalités, toutes formées de la même manière par une procédure commune.

[^1]: CNRTL, Simplifier

modélisation de l’architecture d’un logiciel

id : 20200508111132
dernière édition :
type : modélisation

La modélisation 🔗 est une pratique courante et individuelle des développeurs que les architectes 🔗 viennent porter à plus grande échelle (conception de haut niveau). Les notions traduites ne sont plus des fonctionnalités, mais des cadres, des frameworks 🔗. Démarrer un projet sans plan ne viendrait à l’idée d’aucun architecte 🔗 ; le résultat est au mieux bancal. La modélisation de l’architecture d’un logiciel est garante de sa qualité 🔗.

Visualisation

La recherche au sein de l’architecture logicielle via les outils de visualisation « est essentielle à la compréhension du programme et au test d’hypothèses d’hypothèses. En outre, la recherche permet aux utilisateurs d’inverser les abstractions dans les diagrammes architecturaux et d’accéder aux faits dans le code du programme sous-jacent »[^2] (p.1)

Les langages visuels (annotés, mais opposés aux langages textuels) permettant de modéliser des logiciels ne sont pas des langages de programmation graphique 🔗, mais de visualisation 🔗 de programmes. « le programme est spécifié de manière conventionnelle, textuelle, et les graphiques sont utilisés pour illustrer certains aspects du programme ou de son exécution »[^1] (p.98).

Au cours du cycle de développement 🔗, les modélisations nous permettre de dépasser le cadre unidimensionnel de l’interface qu’est le code source pour penser de manière bidimensionnelle (dessin)[^1] (p.100). C’est un mode de pensée plus proche de nos représentations mentales. Elles permettent de

  • conceptualiser : imaginer l’urbanisation (dessin + dessein → design) ;
  • tester : l’intégrité et la sécurité du logiciel d’après le modèle.

Il est possible de visualiser (séparément) l’ensemble des éléments de la structure d’un logiciel 🔗 via des ordinogrammes 🔗 et ainsi de décrire la circulation des informations et instruction en son sein sur différents axes (ex : transclusions 🔗, circulation des données, interfaces de deux modules 🔗…), par différentes vues 🔗, « en faisant l’abstraction des détails du code source pour montrer une représentation conceptuelle du système »[^2] (p.1). Le découpage en strates, en sous-systèmes permettrait à un (re)utilisateur 🔗 d’explorer le logiciel. Selon leur niveau, ils auront besoin de remonter à la source de cette abstraction, de revenir au code[^2] (p.1).

Une structure que l’on aurait des difficultés à représenter, à simplifier par le dessin, est potentiellement mal construite, n’est pas assez décomposée en modules 🔗 et cannaux.

L’UML 🔗 (Unified Modeling Langage) (ou l’OOSE, Object Oriented Software Engineering, dont il dérive) aident à designer (« dessein + dessin ») ces systèmes d’information.

[^1]: Brad Myers, Taxonomies of Visual Programming and Program Visualization, 1990 [^2]: Susan Elliott Sim, Browsing and searching software architectures, 1999

modélisation du développement logiciel

id : 20211001085442
dernière édition :
type : architecture

La modélisation permet à partir de modèles 🔗 (patrons de conception) d’adapter des notions et concepts pour leur implémentation 🔗 au sein du logiciel. C’est le travail fondamental de chaque développeur. Il s’agit de traduire une idée en une solution technique ; de simplifier une réalité pour la rendre calculable ; de passer du réel au computationnel 🔗.

La solution technique est bornée aux structures de contrôle 🔗 pouvant être inscrites dans l’environnement de développement 🔗. Il s’agit souvant de penser des fonctions 🔗, classes. Les penser en amont permet d’extrapoler leur fonctionnement, d’anticiper leurs appels à différents stades du flot de contrôle 🔗.

On simplifie une réalité en attributs et méthodes ; les caractéristiques qui constituent son état et comment peut évoluer cet état ; car une machine ne fonctionne que sur l’enregistrement et le calcul de valeurs selon le mode de l’inscription computationnel 🔗. Par exemple, de la complexité du concept de personne, on ne retient que le besoin de l’identifier (attributs : id, mail, mot de passe, historique) et de lui donner des permissions (méthodes : accéder, changer mot de passe). Ses méthodes peuvent influencer l’état d’autres modèles (méthodes : ajouter, supprimer).

Cette modélisation peut déboucher sur des visualisations, comme avec les ordinogrammes 🔗.

modes d’écriture technique

id : 20211006191422
dernière édition :
type : inscription

On peut disposer de plusieurs modes d’écriture technique 🔗. Pour une même instruction[^1] (p.173) (ex : « remplace l’entité 1 par l’entité 2 »), on peut exprimer littéralement cette instruction, faire une phrase. On peut également utiliser un vocabulaire contrôlé, exprimer cette instruction par des mots de liaisons normés dans le contexte du projet (ex : entité 2 vers entité 1) ou enfin exprimer cette instruction grâce à un diagramme 🔗 dont on fait varier les étiquettes, les formes et les liaisons.

Le vocabulaire contrôlé peut être issu d’une ontologie 🔗.

C’est ce que Bill Curtis appelle la « dimension symbologique » de la documentation technique, « le degré de concision avec lequel l'information contenues dans la documentation sont représentées […] la densité des caractères ou des symboles nécessaires pour transmettre un concept diminue »[^1] (p.172)

[^1]: Bill Curtis, Experimental evaluation of software documentation formats, 1989

modes de développement logiciel

id : 20211020110609
dernière édition :
type : undefined

Il y a plusieurs modes pour développer un logiciel.

Le mode from scratch conciste à développer le logiciel « de zéro ». Il n’y a aucun fichier à l’origine et on construit progressivement l’environnement de développement 🔗.

C’est une tout autre mode qui se poursuit désormais, le « nouveau développement »[^1] (p.2). Les logiciels reposent désormais sur de nombreuses techniques et outils appartenant a priori à l’environnement de développement 🔗. Si bien que le développement repose désormais sur la rétro-ingénierie 🔗 ; il est nécessaire pour les développeurs de comprendre de nombreuses techniques appartenant à toutes sortes de projets, avant de développer le leur[^1] (p.2). La documentation de ces techniques et outils 🔗 devient ainsi essentielle.

« L’implication de ce changement d’orientation, du développement de nouveaux systèmes à la maintenance et à l’amélioration des systèmes existants, signifie que l’on doit être capable de comprendre la conception du système avant de pouvoir construire par-dessus. Si la conception peut être difficile, il est encore plus difficile de reconstruire et de (re)documenter efficacement la conception des systèmes existants. Reconnaître les abstractions dans les systèmes du monde réel est aussi crucial que de concevoir des abstractions adéquates pour les nouveaux systèmes. »[^1] (p.2)

[^1]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

modularité logicielle

id : 20210313113130
dernière édition :
type : architecture
mots-clés : Samuel Goyet

🔗 module

Une cause d’échec dans le développement logiciel est l’instabilité du système, entraînant un trop de complexité 🔗. Pour pallier cela, le plus simple est toujours le mieux, dans la mesure où la complexité est suffisante (et maîtrisée) pour encadrer le développement et la maintenance du programme 🔗, sans submerger l’équipe. Pour cela on recours à la programmation structurée, on modularise le programme. C’est une méthode d’architecture logicielle 🔗, de design des programmes.

On trouve dans la modularisation du code source une méthode

  • d’organisation des tâches,
  • de modélisation de l’architecture d’un logiciel 🔗,
  • d’écriture des programmes.

« L’efficacité d’une ‹ modularisation › dépend des critères utilisés pour diviser le système en modules »[^3] (p.1053)

Ces critères peuvent être conventionnels ou non-conventionnels, c’est à dire sur-mesure pour un projet donné et ses spécifications 🔗.

Coordonner l’ouvrage

Un code modulaire peut aussi être plus facilement travaillé en équipe. Il est plus facile de jalonné des modules autonomes tout en limitant le risque de conflits durant le versionnement 🔗.

« Ainsi, le programme n’est plus compris comme une suite plus ou moins complexe d’instructions mais comme un assemblage de différentes tâches, chaque tâche pouvant être isolée et recombinée à d’autres »[^2] (p.103)

Selon David Parnas[^3] (p.1054) (cité par Samuel Goyet[^2]), il y a trois bénéfices à recourir à la programmation modulaire :

  • bénéfice managérial : les développeurs travaillent sur des modules séparés en autonomie, sans besoin de se coordonner sur l’exécution des tâches (git flow 🔗) ;
  • bénéfice commercial : il est plus facile de tester le code module par module et ainsi d’éviter les bugs ; pour maintenance, on peut rapidement localiser et modifier une partie du programme selon les modifications nécessaires ;
  • bénéfice cognitif 🔗 : il est plus facile pour un développeur d’appréhender des modules plutôt qu’un système complet ; la modularisation permet « d’écrire un module en connaissant peu le code d’un autre module »[^3] (p.1053)

« Une segmentation bien définie de l’effort du projet assure la modularité du système. Chaque tâche constitue un module de programme séparé et distinct. Au moment de l’implémentation, chaque module et ses entrées et sorties sont bien définis, il n’y a pas de confusion dans l’interface prévue avec les autres modules du système. Au moment de la vérification, l’intégrité du module est testée indépendamment ; il y a peu de problèmes de planification pour synchroniser l’achèvement de plusieurs tâches avant que la vérification puisse commencer. Enfin, le système est maintenu de façon modulaire ; les erreurs et les déficiences du système peuvent être attribuées à des modules spécifiques, ce qui limite la portée de la recherche détaillée des erreurs »[^4]

Concepts

Grady Booch publie Analyse et conception orientées objet et applications (1994) et « énonce les caractéristiques nécessaires d’un paradigme d’ingénierie logicielle permettant de construire des systèmes complexes »[^1] :

  • la décomposition : capacité à diviser le problème en sous-problèmes (composantes) plus simples (réductionnisme 🔗), les sous-problèmes étant plus maniables, plus facilement testables (tests unitaires) et pouvant être traités d’une façon relativement autonome ;
  • l’abstraction 🔗 : capacité de définir un modèle simplifié du système qui met en évidence une partie de ses détails et propriétés, tout en éliminant les autres ; donc l’attention peut se concentrer sur les aspects saillants du problème, et se dispenser des détails moins importants ;
  • l’organisation : procédé consistant à identifier et à gérer les rapports entre les divers sous-problèmes (composantes) à résoudre. On peut ainsi établir des relations organisationnelles entre composantes : les grouper, décrire leurs relations.

On cherche à maîtriser les modules du logiciel par

  • la cohésion : qualité de la structuration interne des modules, pertinence de la division entre les module des éléments du système ; bien réalisé lorsque l’on équilibre comportements spécifiques et connexes.
  • le couplage, interfaçage : type et nombre des interconnexions entre les modules par leurs interfaces respectives ; bien réalisé lorsque le couplage reste suffisamment faible (sans quoi on perd les avantages de la modularisation, la souplesse et la répartition de l’effort)
    • « couplage faible/fort » : peu/beaucoup d’échanges d’informations
    • « couplage lâche » : échange désynchronisé d’informations

tout en assurant la compréhensibilité du système de modules grâce à la rigueur de la documentation du code 🔗, sa cohérence et la gestion des erreurs 🔗.

Mise en place

Il y a plusieurs possibilités découper les spécifications en modules :

  • isoler chaque étape majeure du traitement dans un module (approche la plus courante) ;
  • isoler chaque décision de conception dans un module (et ainsi protéger les leur fonctionnement interne) selon le principe d’encapsulation 🔗.

Ces dispositions induisent des modélisations de l’architecture du logiciel 🔗. La première suggère un organigramme, une arborescence verticale de modules, une « abstraction utile pour les systèmes de l’ordre de 5 000 à 10 000 instructions, mais au-delà, il ne semble pas suffisant »[^3] (p.1056).

Exécution

En terme de comportement logiciel 🔗, les modules peuvent être activés linéairement (premier exemple de mise en place) ou non. Cela ne dépend pas de leur déclaration, définition mais de leur appel.

« les décisions de conception transcendent le temps d’exécution, les modules ne correspondront pas aux étapes du traitement »[^3] (p.1058)

[^1]: Adina Florea, Daniel Kayser, Stefan Pentiuc, Agents intelligents, 2002 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^3]: David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972 [^4]: R. Gauthier, S. Ponton, Designing systems programs, 1971

module

id : 20210421151432
dernière édition :
type : architecture
mots-clés : Samuel Goyet

🔗 modularité logicielle

Un module est une unité simple, autosuffisante de l’architecture du logiciel 🔗 dont il est un sous-système. Les modules sont « discrétisables, agençables et interchangeables »[^1] (p.251) ; « un module peut être compris sans avoir besoin d’une vue d’ensemble du programme »[^1] (p.105). Ils sont conçus lors de la modélisation 🔗.

Un module est extrait de la décomposition fonctionnelle du programme, fruit de cet assemblage, dans une logique combinatoire 🔗. Le statut de module peut être considéré comme une « attribution de responsabilités plutôt que comme un sous-programme »[^3] (p.1054). Le module un modèle 🔗, l’instance d’une métaphore permettant d’identifier sa conception. Elle encapsule 🔗 des données qu’elle traite et protège en son sein.

Il n’est pas un simple « fragment », une unité extraite d’un système brisé, déchiré – un archipel. Il est au contraire une partie intégrante d’un système mécanique dont il devient une « Unité conventionnelle de mesure »[^2]. On doit pouvoir balayer le système du regard et identifier les modules qui se ressemblent (sont formés par le même modèle) et se faire une image du système pour y naviguer.

On conçois un module selon deux modèles 🔗, à la fois pour sa composition (interne) et son interface 🔗 (externe).

« Comme une bonne conception d’ingénierie logicielle suggère que les modules soient relativement petits, le nombre de modules dans un grand système est important. Par exemple, dans un système de 500 000 lignes, avec environ 200 lignes par module, il y aurait 2 500 modules. C’est un ordre de grandeur »[^4] (p.4)

[^1]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^2]: CNRTL, Module [^3]: David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972 [^4]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

mot

id : 20201119203021
dernière édition :
type : inscription
mots-clés : linguisitique

Définition

Un mot est un « son ou groupe de sons articulés ou figurés graphiquement, constituant une unité porteuse de signification à laquelle est liée, dans une langue donnée, une représentation d'un être, d'un objet, d'un concept »^1. On peut fixer le mot sur un support et alors le séparer graphiquement des autres mots par une espace typographique.

Construction

![construction d’un mot](./images fiches/arbre mot.png)

Le schéma ci-dessus permet de saisir tout la complexité de la composition des mots, leur variété. Ainsi la langue (signée) est capable de soutenir un lexique complexe.

D’abord on distingue les monèmes qui peuvent varier en genre, nombre etc. ou qui ont vocation à l’exprimer (les morphèmes) et les autres (lexèmes).

La première catégorie est la plus foisonnante puisqu’elle regroupe les articles, les pronoms, les prépositions etc. (classe fermée), leur combinaison (formes contractées : « de le » devient « du »), les noms et les verbes (classe ouverte) sujets à la conjugaison, à l’accord en genre et en nombre, et leur combinaison (base dérivationnelle, « auto » et « route » fusionnent en « autoroute »). C’est une anatomie du mot dont on distingue les composants : le radical travail- porte un sens, complété par un suffixe (travaill-ons), un préfixe (re-travail) qui complètent ce sens.

La seconde catégorie traite des monèmes qui ne varient pas, soit les radicaux (utilisés couramment avec préfixe et suffixe) et les autonomisables, mots invariants et aboutis dans la variété de leur sens.

Ce schéma est une approche grammaticale de la langue,

namespace, espace de nom

id : 20200622101202
dernière édition :
type : architecture

🔗 espace

C’est un concept informatique spatial dans le sens où il peut couvrir un fichier, un répertoire ou un système plus large, abstrait, comme une ontologie, une taxonomie et autres lexiques limités. Dans cet espace on va inscrire des termes, des identifiants et leur affecter une valeur (chaîne de caractère, nombre, fonction, class, objet… page, fichier…) qui pourra être retrouvée en faisant appel à ce terme.

Autrement dit, c’est la rédaction d’un lexique limité appartenant à un certain contexte. Ce contexte peut être construit sur différents plans, avec des sous-espaces limitant la portée de certains termes. Ce sont les notions de global et local.

Selon le contexte technique certains termes sont réservés et ne peuvent être utilisés par le technicien.

niveaux d’abstraction de la documentation logicielle

id : 20210823190838
dernière édition :
type : documentation

Ci-dessous nous présentons un tableau permettent de distinguer quatre niveaux d’abstraction 🔗 de la documentation logicielle 🔗. En tant que source d’information, nous souhaitons en distinguer le contenu et la composition. Une bonne documentation (en miroir de son code source) est une documentation modélisée. Ainsi nous explicitons la composition d’un modèle 🔗 (relative à son contenu) ainsi que son interface 🔗.

intégration de l’information composition des modèles interface des modèles
interface graphique / textuelle aides contextuelles éléments d’interface composition graphique
documentation d’utilisation manuels, tutoriels, FAQ et encyclopédies section du document hyperliens ciblés sur identifiants
documentation technique cahier des charges, index de l’API, convention de développement spécification 🔗 ou implémentation 🔗 médiateur
code source fichiers dans une arborescence module 🔗 encapsulation 🔗, transclusion 🔗

L’interface des modèles de la documentation technique est assurée par un architecte logiciel 🔗. Lui sait quelles sont les notions les plus importantes et/ou complexes 🔗. Il faut un humain pour expliciter une élaboration. Les autres modèles peuvent être explorées individuellement mais restent potentiellement vaste.

Utilisabilité

On peut étendre le champ de l’utilisabilité logicielle 🔗 à l’ensemble de ces niveaux. Pour pouvoir appréhender chaque niveau d’abstraction, l’utilisateur doit apprendre certaines notions de littération numérique 🔗. Un utilisateur avec une bonne maîtrise de l’outil informatique et des notions du métier auquel répond le logiciel aura globalement plus de facilités à appréhender ces différents niveaux. De l’autre côté, les concepteurs de la documentation logicielle doivent faciliter ce travail de compréhension.

apprentissage utilisateur facilitation concepteur
interface graphique / textuelle respect des guidelines du système d'exploitation
documentation d’utilisation
documentation technique
code source (auto)formation à la programmation et aux modèles de développement

niveaux d’utilisation du logiciel

id : 20210921161727
dernière édition :
type : undefined

Nous distinguons trois niveaux d’utilisation du logiciel, quelle que soit son interface.

  1. Utilisation (utilisateur)
  2. Réutilisation (réutilisateur)
  3. Développement (développeur)

Il peut être déroutant de considérer le même premier niveau d’utilisation pour trois logiciels, quand le premier présente une interface graphique, le deuxième un terminal et le troisième une API 🔗. Pourtant, que j’utilise l’explorateur Windows, Pandoc ou une bibliothèque logicielle 🔗, je suis soit

  1. non manipulateur de son code source et externe à son projet → utilisateur
  2. manipulateur de son code source et externe à son projet → réutilisateur
  3. manipulateur de son code source et interne à son projet → développeur

On peut résume cela avec le tableau ci-desous :

code source projet
utilisateur
réutilisateur x
développeur x x

Si je suis développeur, je suis concerné par la documentation du logiciel comme processus 🔗, car je prends part aux décisions et les applique. Les utilisateurs et réutilisateurs n’ont à faire qu’avec la documentation du logiciel commme produit 🔗.

Connexion des interfaces

Pour un même premier niveau d’utilisation, je peux avoir besoin de compétences très variées. Le cas de l’API 🔗 nécessite que je sache programmer. C’est d’autant plus déroutant que son répertoire de code source (pour sa réutilisation) et ses fichiers d’utilisation sont dans le même espace (bien que l’environnement de développement 🔗 puisse varier, car la réutilisation nécessite des outils et une documentation particulière) où peuvent se confondre les deux premiers niveaux d’utilisation, nécessitant les mêmes compétences en programmation. C’est le cas avec, par exemple, les bibliothèques logicielles 🔗. La différence fondamentale entre deux niveaux d’utilisation est donc mon intention.

Pour les mêmes raisons, il existe une certaine porosité entre la documentation pour les utilisateurs et celle pour les réutilisateurs, développeurs. En effet, l’index de l’API 🔗 est à la fois documentation d’utilisation d’une bibliothèque 🔗 de sa réutilisation et de sa maintenance 🔗. Cette porosité survient du fait que le code source est l’unique interface (d’utilisation et de maintenance) de tout le logiciel.

Documentation des niveaux

Les utilisateurs et réutilisateurs seront intressés par la documentation du logiciel en tant que produit 🔗. En effet, leur intérêt est d’apprendre à utiliser son interface d’usage et de savoir le détourner selon les consignes laissées par l’équipe de développement.

Les développeurs devront en revanche intégrer le projet logiciel avec toutes ses contraintes et idées, lesquelles sont détaillées dans le documentaiton du logiciel en tant que processus 🔗.

En équipe

Flore Barcellini propose[^1] (p.18) une typologie hiérarchique des usagers du logiciel en fonction de leur niveau 🔗 en précisant ce qu’ils sont capables d’apporter au projet logiciel :

  • utilisateurs (actifs) : remonter les dysfonctionnements, proposer des améliorations ;
  • développeurs :
    • contributeurs : ils ajoutent et maintiennent les composants du logiciel ;
    • core developers : ils ont une vue d’ensemble sur le projet, s’assurent de la qualité du code et de l’environnement du logiciel 🔗 en plus d’y contribuer.

[^1]: Flore Barcellini, Conception de l’artefact, conception du collectif, 2008

niveaux des (ré)utilisateurs logiciel

id : 20210220100014
dernière édition :
type : undefined

Alistair Cockburn présente trois niveaux de compréhension de l’utilisateur face à une API 🔗[^1] (p.22) :

  1. suiveur (following) : Ils sont à la recherche d’une procédure qui fonctionne, même s’il y a plusieurs manières de faire, ils vont se contenter d’une seule sur ce simple critère. Ils ont besoin rapidement du sentiment d’être arrivé à entrer dans le système d’utilisation et d’apprentissage. C’est une démarche que l’on veut amorcer avec les démonstrations de fonctionnement 🔗 ; ces personnes sont rassurées quand il y a beaucoup de détails dans le manuel d’apprentissage.
  2. détaché (detaching) : Ils sont à la recherche de l’échec, pour faire l’expérience des limites des procédures qu’ils explorent désormais une à une pour utiliser la plus adaptée au système.
  3. fluidité (fluent) : Ils improvisent, ne cherchent plus à suivre une procédure plutôt qu’une autre, sont émancipés du manuel.

Ces écarts de niveaux se concrétisent dans la documentation logicielle 🔗 par un aménagement des informations. Ainsi, les suiveurs ont besoin d’une démonstration de fonctionnement 🔗 rapide, basique, peu détaillée, leur donnant une procédure fonctionnelle. Par ailleurs, ces utilisateurs sont rassurés quand il y a de nombreux détails dans la documentation, les guidant vers cette solution. Les fluides attendent des explications très ciblées et très détaillées[^2] (p.15). Ils sont capables d’entrer dans un réseau hypertextuel 🔗 de connaissances et d’y naviguer.

« La discipline, les compétences et la compréhension contrecarrent le processus, le formalisme et la documentation »[^1] (p.126)

La documentation du logiciel 🔗 ne peut compenser la rigueur et la compétence des utilisateurs du logiciel. La communication humaine reste le principal médium, reposant sur les acquis de personnes devant être expérimentées. Ajouter plus de contraintes (processus dans le projet ou formalisme dans l’utilisation) tasse le niveau global des personne, ne pouvant poursuivre leur progression, sans leur donner plus de discipline dans leur utilisation. Hors, c’est la discipline qui leur permet d’élever leur niveau[^1] (p.131). Il ne faut pas confondre la documentation avec la compréhension[^1] (p.130) et le formalisme avec la compétence[^1] (p.131).


Modèle non cohérent avec les niveaux d'utilisation du logiciel 🔗. C’est pas bon du tout !

On définit trois niveaux d'utilisateur du logiciel, d'après les différents niveaux d'utilisation 🔗 possibles.

utilisateur (re)utilisateur développeur
programmation ne sait pas sait programmer sait programmer les outils d'équipe
abstraction

Savoir programmer donne une autre vision du logiciel. Un développeur sait adopter plusieurs angles de réflexion pour une même problématique quand un simple utilisateur sans connaissances en programmation n’adoptera qu’un parcours linéaire de l’information pour un problème donné.

L’utilisateur peut être un développeur. La documentation utilisateur peut être composée pour tout ou partie d’instructions relatives à la réutilisation d’un logiciel par son code source. Toujours est-il que cette documentation ne renseigne pas l’utilisateur sur le logiciel en tant que projet. Amener un utilisateur savant à s’approprier des notions de l’architecture logicielle 🔗.


Définir des niveaux d’utilisation de la documentation logicielle 🔗 nécessite de couvrir de nombreux domaines. Il s’agit globalement d’évaluer la littératie 🔗 des utilisateurs. Ils cherchent à trouver des informations plus ou moins abstraites avec un niveau plus ou moins avancé sur les techniques logicielles. De l’utilisateurs lambadas au développeur expert, nous essayons de distinguer différents niveaux et leurs aptitudes.

Abstraction

L’abstraction 🔗 est la capacité des utilisateurs à comprendre les différents niveaux de modèles 🔗 (interfaces de compréhension) de la documentation. Au cours de leurs recherches, les utilisateurs peuvent être confrontés à différents niveaux d’abstraction de la documentation logicielle 🔗, comme une interface graphique, voire le code source. En mettant de côté la différence d’utilisation entre ces deux interfaces, il est important de considérer que l’interface graphique suggère des modèles d’utilisation et de traitement quand le code source détaille méticuleusement les comportements de modules 🔗 dont la portée fonctionnelle est bien plus courte (nécessitant de comprendre plus de notions pour une même fonctionnalité). Les modules 🔗 forment un tout au moins aussi hétérogène que l’interface 🔗 reliant chacun d’entre eux.

Un utilisateur avec peu d’abstraction 🔗 mais un bon niveau dans l’environnement de développement 🔗 sera capable de comprendre les modèles d’implémentation 🔗 du logiciel, mais pas leurs interfaces 🔗. L’effort est dans l’analyse des interfaces 🔗 (limites et relations). Cet utilisateur devra se trouver à un haut niveau d’abstraction (où les interfaces sont unifiées, où il n’y a pas besoin de les analyser) pour pouvoir distinguer les parties du logiciel où il ira chercher ses réponses. Ainsi, il peut être difficile pour cette personne de naviguer dans certaines parties de la documentation logicielle 🔗. Il ne pourrait, par exemple, pas anticiper la correspondance entre plusieurs fonctionnalités quand la documentation n’en détaillerait qu’une.

Il n’est pas question de savoir si un utilisateur peut descendre à toutes les niveaux de modèle et comprendre leur composition et l’interface 🔗 de leur composants. L’intérêt pour l’utilisateur est plutôt de savoir quelle sont les relations qu’entretiennent ces niveaux de modèles et sur lequel il doit étudier le système pour pouvoir le saisir efficacement, comme le ferait un utilisateur avec un bon niveau d’abstraction.

Le niveau en informatique (général) et dans le domaine métier que couvre le logiciel aident nettement à gagner en abstraction. Il ne faut pas s’attendre à avoir un bon niveau pour tous les logiciels et leur documentation. Toutefois, les modèles 🔗 suivant les pratiques d’un métier peuvent être plus facilement saisis, et ce aux différents niveaux d’abstraction de la documentation logicielle 🔗. Un comptable peut comprendre le rapport entre les champs d’un formulaire (niveau d’interface graphique) tandis qu’un développeur mal à l’aise avec ces notions aura du mal à implémenter (niveau du code source) un outil comptable.


🔗 DigComp, évaluation des compétences numériques

La typologie d’utilisateurs suivante débute avec des utilisateurs amenés à consulter la documentation 🔗 à différents niveaux d’abstraction 🔗. Ils vont au-delà de la simple utilisation du logiciel (suggérée par son interface) pour entamer une démarche de compréhension approfondie des différentes strates du logiciel 🔗.

Les utilisateurs peuvent être rapidement mis face à code ; de nombreux logiciels ne proposent plus d’interface 🔗 passé un certain niveau d’utilisation. C’est le cas de certains logiciels open source dont l’interface repose sur un terminal, mais aussi de certains logiciels professionnels supportant les scripts 🔗.

La programmation est plus ou moins complexe et nécessite un certain niveau de compétence pour faire face à l’abstraction. Pour chaque niveau on liste des attentes pouvant être satisfaites par la documentation. Un utilisateur de niveau 4 pourra avoir les attentes des niveaux qui le précède.

  1. utilisateurs « non avertis », sans formation à l’informatique
    • trouver les consignes d’installation
    • comprendre le fonctionnement du logiciel, qui n’est pas un induit par son interface
    • comprendre la démarche et la genèse du logiciel
    • trouver un accès au support (déclarer des dysfonctionnements ou proposer des modifications)
  2. utilisateurs « avertis », avec des notions sur la donnée et sa circulation
    • comprendre l’utilisation et l’espace des données
    • comparaison avec d’autres logiciels
    • comprendre le fonctionnement externe du logiciel, les technologies avec lesquelles il est en lien
  3. utilisateurs « avancés », avec des notions de programmation
    • comprendre le fonctionnement interne du logiciel, l’arborescence, les liaisons entre les structures de contrôle
    • comprendre comment modifier certaines parties du logiciel, les plus détaillées par la documentation
    • comprendre comment utiliser les outils de développement
  4. utilisateurs « experts », avec des notions de développement
    • comprendre toute la complexité du logiciel pour le réécrire, faire de la résolution de bug, du refactoring
    • comprendre comment modifier la documentation dans son architecture

[^1]: Alistair Cockburn, Agile Software Development, 2002 [^2]: Ian Sommerville, Software Documentation, 2001

nommage des variables

id : 20210927140801
dernière édition :
type : documentation
mots-clés : code

Pour nommer les variables (fonctions, classes) dans un projet logiciel on peut faire des typologies, un thesaurus 🔗. Cela faciliter la référence à ces concepts, méthodes, attributs via d’autres documents de la documentation logicielle 🔗.

L’espace de nom 🔗 dans l’extrait de code suivant est particulièrement explicite ne serait-ce que par le lexique employé. Il faut être exigeant sur l’écriture technique 🔗 employée. La fonction authentificate nécessiterait d’avantage de précision tandis que ban_user_ip se suffit à elle-même ; on trouvera plus de précisions via la classe Banishment.

class Admin extends User {
    public $name;
    public $mail;
    private $password;

    public function authentificate() {…}

    public function ban_user_ip($user_ip) {
        $ban = new Banishment($user_ip);
        $ban->set_period(1, 'year');
        $ban->apply();
    }
}

Ce lexique pourra ensuite donner une taxonomie, laquelle pourra être réutiliser dans la documentation du logiciel ou entre les développeurs lorsqu’ils évoquent certains contextes de l’espace de nom 🔗.

notion de paradigme

id : 20200623110109
dernière édition :
type : processus

Dans un modèle

Thomas Samuel Kuhn écrit en 1962 La structure des révolutions scientifiques le terme paradigme désormais couramment employé pour désigner un modèle quelconque. Ce mot vient du grac ancien paradeïgma qui signifie « exemple », « modèle ».

« Pour Kuhn, il s'agit des principes et méthodes partagés par une communauté scientifique »[^1]. Ainsi, il rompt avec une partie de l'histoire des sciences qui voudrait une « évolution continue par accumulation du savoir selon la méthode scientifique grâce à des découvertes individuelles »[^1] pour admettre que des groupes (« maîtres, contemporains et successeurs »[^1]) se forment et influencent la recherche plutôt que des individus. C'est ce que ce Kuhn appelle « science normale » et c'est elle qui « prépare l'étudiant à devenir membre d'une communauté scientifique »[^2]

« L'utilité d'un paradigme est de renseigner les scientifiques sur les entités que la nature contient ou ne contient pas et sur la façon dont elles se comportent. […] En apprenant un paradigme, l'homme de science acquiert à la fois une théorie, des méthodes et des critères de jugement, généralement en un mélange inextricable »[^2]

Ainsi Kuhn réfute « l’opinion positiviste classique selon laquelle l’observation est l’arbitre neutre entre les théories concurrentes » : dans une certaine mesure, les scientifiques appliquant différents paradigmes ne perçoivent pas le monde de la même manière.

Un paradigme « détermine la légitimité des problèmes et aussi des solutions proposées » soit « l'articulation des phénomènes et théories que le paradigme fournit déjà »[^2]

Par « inextricable » il faut comprendre « Qui ne peut être démêlé ; dont on ne peut reconnaître les éléments »[^3]. Dans ce nuage d'idées, le scientifique effectue un « travail d'ajustement, de mise au point et de précision du paradigme », ce qui « permet la transmission et le perfectionnement du savoir. Mais, cela a pour inconvénient une dogmatisation »[^1]. Patrick Juignet souligne l'aspect « cumulatif-intégratif » de la science, essentiel pour les jeunes chercheurs qui n'ont pas à ré-inventer le travail de leurs pairs, mais avec le risque de rester enfermé dans une même arborescence de connaissances et de tourner en rond, non pas pour un individu, mais pour tout un groupe de recherche.

Révolution

Les paradigmes sont inconciliables et passer de l'un à l'autre est un long processus discontinu, difficile ; une crise. Ainsi la révolution, le passage d'un paradigme à l'autre est inévitable et « bien que le monde ne change pas après un changement de paradigme, l'homme de science travaille désormais dans un monde différent »[^2].

Échos

Pour les développeurs

Remplace « scientifique » par « développeur » et on a exactement l'origine des paradigmes de programmation.

🔗 paradigmes de programmation

Pour les techniciens

Patrice Flichy écrit sur le « paradigme technique » qui « indique les directions de recherche à entreprendre et celles qui au contraire doivent être abandonnées »

[^1]: Patrick Juignet, Les paradigmes scientifiques selon Thomas Kuhn, 2015 [^2]: Thomas Samuel Kuhn, La structure des révolutions scientifiques, 1962 [^3]: Larousse, inextricable

notions d’algorithmique

id : 20200519215026
dernière édition :
type : programmation
mots-clés : Anthony Masure

Un algorithme est un énoncé, une liste d’instructions finie permettant de résoudre un problème de manière systématique. Il permet d’automatiser le traitement de l’information et d’en optimiser la gestion.

« L’algorithme est dit correct si la solution est juste. Son efficacité est mesurée par la vitesse de résolution, ainsi que par les ressources utilisées par les machines pour l’effectuer »[^1]

Typologie de problèmes

Le problème « Trouver le plus court chemin de l'IUT à la place de la Victoire à Bordeaux » n'est pas intéressant d'un point de vue algorithmique car il motive une réponse unique. « Trouver le chemin le plus court entre deux adresses a et b à ville » offre en revanche de nombreuses possibilités de réponse (extrant, output ou sortie) en même temps que ses trois paramètres (intrant, input ou entrée) qui limitent son champ : a, b et ville. Aussi, la première proposition est une instance de la seconde.

🔗 instance informatique

Les deux propositions peuvent être traitées algorithmiquement, mais programmer une fonction 🔗 telle que décrite dans la seconde permet de résoudre une gamme entière de problèmes.

Ambiguïté

La notion d’algorithme ne se limite pas à l'informatique mais constitue le principal matériau de la programmation informatique. En effet, ils permettent de prévoir un enchaînement d'instructions souple et fiable. Pour satisfaire au mieux ce besoin ils se construisent avec des langages non ambigus, formels.

🔗 code source

[^1]: Anthony Masure, Le design des programmes, 2014

novlangue numérique

id : 20210516155921
dernière édition :
type : undefined
mots-clés : politique

La Silicon Valley est une source « intarissable de concepts de mauvaise qualité et de paradigmes douteux - du wiki-tout au i-quelque-chose, du e-rien au tout-ouvert »[^1].

Tim O'Reilly est le PDG de O'Reilly Media. « Au cours des quinze dernières années, il nous a donné des joyaux de précision analytique tels que ‹ open source ›, ‹ Web 2.0 ›, ‹ gouvernement en tant que plate-forme › et ‹ architecture de la participation › »

[^1]: Evgeny Morozov, The Meme Hustler, 2021

numérique

id : 20200905201903
dernière édition :
type : undefined
mots-clés : Bruno Bachimont, Milad Doueihi

Selon Milad Doueihi la culture numérique est « faite de modes de communication et d’échange d’informations qui déplacent, redéfinissent et remodèlent le savoir dans des formes et des formats nouveaux, et de méthodes pour l’acquérir et le transmettre ».[^2] (p.37)

Selon Bruno Bachimont[^1], le numérique pourrait être considéré comme :

  • objet d’étude en tant que tel ;
  • outil : « ensemble de solutions techniques » utilisées pour faire face à différentes difficultés ;
  • milieu : « ce à travers quoi on se rapporte à notre environnement ».

Aussi, le numérique serait constitué de deux éléments :

  • codification : ensemble d’éléments pouvant être distingués et dont les unités n’ont pas de sens propre, pas plus que l’ensemble qu’elle forment. Leur sens est arbitraire : il n’est pas dans leur essence et aurait pu être autre.
  • manipulation :

🔗 espace numérique

[^1]: Bruno Bachimont, Rhétorique de l’intelligibilité, vers des humanités du numérique, 2020 [^2]: Milad Doueihi, La grande conversion numérique, 2008

numérisation

id : 20201002212257
dernière édition :
type : processus
mots-clés : Marcello V.R.

🔗 grammatisation

L’enregistrement numérique (« échantillonnage ») est discontinu : « on ne considère pas l’ensemble du son, mais seulement les changements qui se produisent à des intervalles déterminés »[^1]. C’est un concept mathématique : la discrétisation 🔗. C’est ce processus d’échantillonnage qui permet de transformer le continu du réel en une série de chiffres. On va tenter de diminuer et cacher au mieux cette imperfection intrinsèque, mais bien nécessaire pour la manipulation calculatoire par une machine computationnelle.

Codification

🔗 code source

Avec le binaire il est possible d’échantillonner un contenu analogique, de le retranscrire en binaire, sous forme de circuit électronique (ouvert, fermé), sur la surface d’un CD (creux, plat) etc.. Le même échantillonnage pourra être gravé sur différents supports. Il sera re-calculer pour chaque affichage.

[^1]: Michael E.S, Marcello V.R., Pratiques de l’édition numérique, 2014

obésité du web

id : 20210705140638
dernière édition :
type : undefined

Par « obésité du Web » on dénonce de nombreux phénomènes :

  • l’augmentation du poids des pages Web, suivie par l’augmentation des ressources nécessaires pour l’afficher et finalement l’importance des transferts que nécessite l’acheminement de toutes ces données ;
  • la personnalisation excessive de l’expérience utilisateur et sa polution par des animations et intérruptions de lecture.

Les causes sont diverses :

  • augmentation du nombre d’images, de biliothèques 🔗 JavaScript de leur poids ;
  • connexion à des services de collecte et/ou de distribution de données (tracking, publicités et contenus).

Ainsi, les inscriptions dans la source HTML ne sont plus uniquement dédiées au contenu lisible par le lecteur, mais à l’intégration de services. Pire, une grande partie du contenu n’est plus inscrite dans les fichiers, mais appelées par des requêtes asynchrones (AJAX 🔗) puis intégrées. Sur la bande passant circulent en permanence des données entre client et serveur 🔗.

Limiter l’obésité

Le fait que le CSS et le JavaScript poussent toujours plus loin le potentiel d’affichage ne doit pas induire le réflèxe d’en abuser. Les principes du brutalist web design 🔗 limitent drastiquement les contenus intégrés aux pages.

Les générateurs de sites statiques comme 11ty, Hugo ou Jekyll permettent de générer des fichiers HTML contenant l’ensemble du contenu de la page. Il ne reste qu’à appeler les styles, quelques scripts pour l’intéraction et la page est complète. Le transfert est bien plus rapide vu le faible nombre de requêtes à effectuer.

objet informatique

id : 20210130110228
dernière édition :
type : inscription

🔗 programmation orientée objet 🔗 instance informatique

Un objet est un conteneur possédant différents attributs dont il hérite. Il est modèle d’une réalité propre à un espace numérique 🔗 donné. Ainsi, sa nature est contrôlée et il peut changer d’état à volonté dans ce cadre.

🔗 métadonnées

ontologie

id : 20200809102622
dernière édition :
type : architecture
mots-clés : Bruno Bachimont

Une ontologie est à l’origine une pratique philosophique antique qui consiste à traiter les êtres dans leur généralité (« Qu’est-ce que l’être ? »). Elle définit le vocabulaire dans un domaine donné (permettant de mettre en place un vocabulaire contrôlé) pour que les agents qu’il intègre puissent se comprendre en vue d’une opérationnalisation[^2] que l’on va étudier un champ de connaissance et le structurer par le sens.

« les chercheurs dans le domaine de l’intelligence artificielle se sont appropriés le terme pour désigner une organisation logique et formelle d’un domaine de connaissance pour permettre à une machine d’en manipuler les différents objets, leurs caractéristiques et leurs logiques »[^3].

Elle permet de sémantiser les relations entre les entités auxquelles elle fait référence. Deux items peuvent avoir une relation caractéristique comme « apaprtient à », « est un degré de ». On va plus loin en permettant de sémantiser les éléments eux-même par le biais de ces relations. L’ontologie permet de faire une inférence, de déclarer (d’après sa relation à B) que C est donc logiquement enfant de C.

Représentation

Une ontologie est un « ensemble structuré des termes et concepts représentant le sens d’un champ d’informations »[^1]. Ce sont des constructions linguistiques ; les mots forment des nœuds et leur sémantique des liens.

Une ontologie permet de décrire :

  • des classes, types d’entité du domaine décrit ;
  • des propriétés, différents types de relations qui caractérisent une classe ;
  • une logique, c’est-à-dire des règles ou des comportements associés à une classe et/ou à une propriété ;
  • des instances, c’est-à-dire des unités héritant des propriétés de classes.

Une ontologie prend naturellement la forme d’un graphe 🔗. Cette forme influe sur son interprétation, mais ne programme pas l’ontologie.

Programmation

« Les langages formels possèdent donc la remarquable propriété de spécifier à la fois le comportement d’un dispositif et de prescrire une interprétation »[^2]

Les ontologies apparaissent par exemple dans les fichiers XML (et ses variantes) comme une « signature »[^2], d’une balise dont le contenu va alors prendre un sens. Ci-dessous, cette balise définis le titre du document tel que l’indique la balise dc:title tirée de l’ontologie interprétatives[^2] Dublin Core.

<dc:title>Dublin Core™ in XML</dc:title>

[^1]: Wikipédia, Ontologie (informatique) [^2]: Bruno Bachimont, Ingénierie des connaissances et des contenus, 2007 [^3]: Gautier Poupeau, Les technologies du Web sémantique, 2011

opposition numérique/analogique

id : 20200613160247
dernière édition :
type : processus
mots-clés : Marcello V.R.

Analogique

« Le mot ‹ numérique › est initialement utilisé pour caractériser le mode d’enregistrement de sons, d’images ou de vidéos en opposition à l’analogique ». Macello V.R. prend l’exemple du vinyle pour saisir la notion d’analogique, car il « [reproduit le] son de façon analogue à la réalité »[^1] :

« Concrètement, la pointe du dispositif d’enregistrement est ébranlée par le son et reproduit un mouvement analogue à celui du son. La courbe qui en ressort est continue et représente fidèlement le mouvement du son dans les moindres détails et dans la continuité du temps. Entre chaque point de cette courbe, il y a des points à l’infini […] la courbe est donc ‹ dense ›, dans le sens mathématique du mot »[^1]

Si une telle reproduction peut être qualifiée de parfaite, c’est au détriment de la qualité du support, fragile, s’usant rapidement. Aussi, chaque copie perd en qualité : on s’éloigne de l’enregistrement initial. Le temps agit donc irrémédiablement sur une reproduction analogique.

Numérique

La numérisation n’est pas une dématérialisation, mais une re-materialisation[^2]. Elle n’est pas strictement fidèle à la forme analogique du contenu et son support (disque dur, CD…) reste fragile. Son impact énergétique est aussi bien plus important. Toutefois, la copie de la forme numérique est exacte : il est possible de dupliquer parfaitement, en symétrie, une œuvre numérisée.

🔗 numérisation

[^1]: Michael E.S, Marcello V.R., Pratiques de l’édition numérique, 2014 [^2]: Dominique Vinck, Humanités numériques: la culture face aux nouvelles technologies, 2016, p.35

optimisation

id : 20211014184351
dernière édition :
type : processus

L’optimisation consiste à rendre plus effiace le traitement d’un processus connu et prévisible. On ne peut optimiser un système imprévisible, complexe 🔗. Il faut pouvoir saisir l’ensemble de ses paramètres pour adapter notre approche avec différentes techniques.

ordinogrammes

id : 20211003130958
dernière édition :
type : modélisation

Un ordinogramme est un diagramme 🔗 représentant l’enchaînement des opérations d’un algorithme 🔗 executé sur un ordinateur (« ordin-ogramme »). Les ordinogrammes se rapprochent des organigrammes, car ils représentent des entités caractérisées fonctionnellement par leurs liaisons pour former une structure.

Formes

On distingue trois formes d’ordinogrammes contenant de plus en plus d’informations[^1] (p.173) :

  • séquentiel : flot de contrôle 🔗 séquentiel ;
  • ramifications : flot de contrôle 🔗 avec alternatives causées par les structures de contrôle 🔗 ;
  • arborescence 🔗 : flot de contrôle 🔗 avec portée 🔗 et alternatives (moins précises) causées par les structures de contrôle 🔗.

Ces dispositions diffèrent sur la représentation des « chemins d’exécution d’un programme et l’étendue des processus affectés par une expression conditionnelle »[^1] (p.172), lesquels sont essentiels pour saisir le flot de contrôle 🔗, savoir quels sont processus sont affectés.

« Les méthodes courantes de représentation les architectures logicielles incluent les dessins de boîtes et de lignes, les arbres hiérarchiques et les boîtes imbriquées. Il s’agit abstractions structurelles […] ; elles laissent délibérément de côté certains détails, de sorte que certains concepts peuvent être décrits plus clairement »[^3] (p.1)

Intégration

Scott Robert Tilley propose un schéma et quatre critères quant à l’intégration des ordinogrammes dans la documentation ; « On peut alors représenter un système logiciel comme un cube, dont chaque ‹ tranche › bidimensionnelle correspond à une stratification particulière […] un hy-percube à quatre dimensions : un cube tridimensionnel se déplaçant dans le temps »[^4] (p.5) :

  • les vues 🔗 que les ordinogrammes permettent successivement d’appréhender pour un même système ;
  • les couches (strates) d’aperçues ;
  • le nombre d’artefacts 🔗 qu’ils représentent ;
  • leur mise à jour au fur et à mesure de l’évolution de la documentation.

Efficacité

Selon une étude expérimentale de Bill Curtis[^1] (p.171) les ordinogrammes

  • nécessitent pout être effiace d’avoir une bonne expérience de leur utilisation ;
  • permettent d’éviter des tests non-pertinents ;
  • aident à localiser les défauts de programmation, comme les effets de bord 🔗, mais plus difficilement à les analyser.

Leur utilité diminue quand on essaie de sortir de l’analyse du flux de contrôle représenté à sa relation avec d’autres procédures. Aussi, leut utilité globale reste limitée[^1] (p.169).

« la raison pour laquelle les diagrammes de collaboration ne sont pas mentionnés dans les méthodologies est qu’ils sont artefacts temporaires. Ils sont utiles pour créer des designs et pour communiquer sur des situations spécifiques, mais ils ne sont pas conservés dans la documentation de conception »[^2] (p.54)

[^1]: Bill Curtis, Experimental evaluation of software documentation formats, 1989 [^2]: Alistair Cockburn, Agile Software Development, 2002 [^3]: Susan Elliott Sim, Browsing and searching software architectures, 1999 [^4]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

organisation d’un système d’information

id : 20200501120436
dernière édition :
type : processus
  • Quoi — Qu’est-ce qui est à organiser ?
    • Quel est le domaine couvert, son ampleur ?
    • Comment se fait la relation entre les objets 🔗 (données et leur métadonnées) ?
    • La collection existe-elle déjà, faut-il la créer, est-elle finie ou en évolution constante ?
    • Les ressources suivent-elle un cycle de vie ?
  • Pourquoi — Pourquoi l’a-t-on organisé ?
    • Quelles seront les interactions ou les services et à destination de qui ?
    • Les utilisateurs sont-ils des personnes ou des machines ?
  • Jusqu’où — Jusqu’à quel point est-ce vraiment organisé ?
    • Quelle étendue dans les classification et les relations ?
    • Est-ce réalisé centralement ou influencer par des organes externes, est limité ou spontané ?
  • Quand — À partir de quand cela a-t-il été organisé ?
    • L’organisation est-elle imposée dès la production des ressources, au moment de leur mise en collection, uniquement quand des relations sont établies ?
    • Y-a-t’il une réglementation ou des bonnes pratiques ?
  • Comment — Comment (ou par qui) cela a-t-il été organisé ?
    • Le remplissage est automatique, fait par des individus, issus de groupes formels ou non ?
    • Les organisateurs sont-ils aussi les utilisateurs, y a t-il une gouvernance ?

🔗 outils de classement

[^1]: Robert J.Glushko, The Discipline of Organizing, 2013

organisation, structure et système

id : 20200829163448
dernière édition :
type : architecture
mots-clés : informatique

Pour ces trois notions on a l’idée d’un ensemble cohérent d’éléments (une complexité variable). La définition de ces notions diffère en degré.

🔗 travailler la complexité

Définitions

Organisation

Ce terme tient ses origines de la médecine : une manière pour les praticiens de décrire les échanges entre les organes. Ainsi une organisation est vivante.

Edgar Morin présente dans son œuvre La Méthode la définition suivante d’une organisation, capable d’échanges internes, mais aussi externe, tel un système :

« [C’est la] propriété d’un système capable à la fois de maintenir et de se maintenir, de relier et de se relier, de produire et de se produire »[^1]

On confond souvent l’organisation et l’organisé qui forment un même objet autonome.

« L'organisation, la chose organisée, le produit de cette organisation et l'organisant sont inséparables »[^2]

Structure

Les éléments d’une structure constituent une construction spécifique. Elle a une apparence et peut être observée de l’extérieur, suggérant que c’est un objet fini.[^3]

Système

C’est une construction théorique, de l’esprit, une combinaison de concepts. Ses éléments sont des propositions issues d’autres systèmes dont il est nécessairement dépendant.[^4]

Analyse

On peut étudier ces ensembles selon quatre questions du principe SAGACE :

  • fonction : il fait quoi ?
  • environnement : dans quoi ?
  • finalité : pour quoi ?
  • transformation : en devenant quoi ?

[^1]: Edgar Morin, La Méthode, 1977 [^2]: Paul Valéry [^3]: CNRTL : https://www.cnrtl.fr/lexicographie/structure [^4]: CNRTL : https://www.cnrtl.fr/definition/système

outils de classement

id : 20200501120506
dernière édition :
type : architecture
mots-clés : scienceinformation

Outils de classement

On cherche à la fois à distinguer les contenus cogitivement, visuellement et physiquement :

  • Normes bibliographiques :
    • métadonnées : titre, auteur, éditeur… Dublin Core…
    • identifiants : ISBN, DOI… clés…
    • catégories :
      • taxonomie (lexique contrôlé) : catégories
      • folksonomie (lexique des utilisateurs) : tag, hashtag
  • thesaurus et ontologies 🔗
  • Classifications
    • Décimal Dewey
    • Classification Décimal Universelle (CDU)
    • Classification combinatoire Ranganathan

Autres outils

Le Functional Requirements for Bibliographic Records (FRBR) ou « spécifications fonctionnelles des notices bibliographiques » est une analyse par strates d'un document. Ce découpage est particulièrement pertinent pour les œuvres multi-support :

  1. œuvre (création intellectuelle vehiculé par le document) : Alice aux pays des merveilles par Lewis Carroll ;
  2. expression (interprêtation de cette œuvre) : adaptation cinématographique par Tim Burton ;
  3. manifestation (représentation des caractéritiques de la publication) : édition collector du DVD ;
  4. item (unité) : DVD lui-même.

paradigme de l’imprimé

id : 20200815163702
dernière édition :
type : processus
mots-clés : scienceinformation

« ‹ mettre en forme › un contenu est tout à fait autre chose que de penser ensemble ‹ la forme et la fonction › […] Est-il vraiment possible de penser des formes en attente de sens ? Que voudrait dire un sens désincarné, qui ne s’incarnerait pas a priori dans des formes ? »[^1]

« la mimesis d’une forme historique est le signe d’une incapacité à penser la forme en tant que structure »[^1]

Si l’intention doit donner la forme, la forme reste bien entendu signifiante. Elle s’exprime sur un support et appelle un ressentis de l’utilisateur. Pourtant, la forme prédomine encore largement nos publications.

« [le skeumorphisme] nous permet de comprendre que les formes dominantes de lecture à l’écran sont davantage une tentative de restitution de la lecture sur support papier qu’une réflexion sur les nouvelles possibilités induites par le passage au numérique »[^1]

🔗 skeuomorphisme

[^1]: Anthony Masure, Le design des programmes, 2014

paradigmes de programmation

id : 20200530191442
dernière édition :
type : architecture
mots-clés : code

🔗 notion de paradigme

La programmation informatique répond à un problème de manière systémique (algorithmes). Les paradigmes de programmation sont destinés à structurer cette réponse formulée avec un langage de programmation 🔗. Il s’agit de considérer la programmation comme la production d’un texte et de réfléchir à la meilleure inscription 🔗 que l’on puisse en faire sur son support.

Il existe plusieurs paradigmes de programmation, plus ou moins lourds à mettre en place, plus ou moins adaptés selon les langages utilisés et les modalités du projet.

Il ne s’agit pas d’appréhender un problème (on parlerait alors de méthodologie), mais de se concentrer sur son implémentation 🔗 : sa transcription avec un langage de programmation.

Selon le paradigme choisi, on va faire varier le type et la forme des structures de contrôle 🔗 pour atomiser ou au contraire concentrer les éléments du code source. On cherche à optimiser la structure du logiciel 🔗.

On différencie deux types de paradigmes :

  • impératif 🔗 : composants très structurés dans une logique d’anticipation ;
  • déclaratif 🔗 : composants efficaces en vue d’obtenir un code essentiellement fonctionnel.

« Les manières classiques d’aborder la difficulté de l’état [du programme] sont la programmation orientée objet, qui associe étroitement l’état et le comportement correspondant, et la programmation fonctionnelle qui, dans sa forme pure, évite l’état et les effets secondaires »[^1] (p.1)

Pour chaque paradigme on va utiliser un type d’artefact comme présenté dans le tableau ci-dessous selon nos besoins.

Paradigme Artefact Préoccupation
procédurale fonction Découper le code en portions
orientée objets classe Données sous la forme d'objets Impératif
orientée aspects aspect Fonctionnalités transverses
fonctionnelle Déclaratif
orientée agents agent
lettrée

[^1]: Ben Moseley, Peter Marks, Out of the Tar Pit, 2006

paysage logiciel

id : 20211015171033
dernière édition :
type : documentation

D’après l’expression de Susan Elliott Sim, un paysage logiciel (software landscape)[^1] (p.3) permettrait de naviguer au sein de l’architecture d’un logiciel 🔗. Il serait généré via un analyseur sytaxique qui va référencer les appels fonction et ainsi permettre de cartographier le logiciel, les connexions entre les variables 🔗 et structures de contrôle 🔗 qui le composent, pour former un graphe 🔗.

« L’utilisateur se voit tout d’abord présenter une vue d’ensemble du système logiciel et il peut zoomer sur les sous-systèmes qui l’intéressent. Les arêtes et les nœuds peuvent être filtrés de manière sélective. et des informations supplémentaires sont disponibles par le biais de clics de souris »[^1] (p.3)

Un tel outil permettrait de « familiariser les nouveaux venus dans l’équipe de maintenance avec le système logiciel documenté, fournir aux membres expérimentés de l’équipe une vue d’ensemble d’un sous-système peu familier, valider les relations entre les sous-systèmes, et vérifier les décisions de réingénierie »[^1] (p.3) et ainsi de servir tous les réutilisateurs ou développeurs du logiciel 🔗. Cet outil leur confère une notion des relations entre les entités leur permettant d’éviter, de corriger des erreurs de développement.

Il reste un écart entre cette vue conceptuelle, les concepts décrits par le paysage logiciel et le code source. Ce décalage nécessite que les utilisateurs du paysage logiciel sachent inverser l’abstraction, faire rétro-ingenierie 🔗, revenir par la visualisation 🔗 à la source et la comprendre[^1] (p.3).

[^1]: Susan Elliott Sim, Browsing and searching software architectures, 1999

performativité du code

id : 20210430223919
dernière édition :
type : programmation

Est performatif un texte ou une parole qui énonce une action et l’accomplit par son énonciation. L’action ou l’état décris dans les phrases « Je te conseille », « Vous êtes coupable » est effectif dès sa prononciation. On retrouve cette idée dans la programmation 🔗 étant donné que chaque inscription est suivie (à l’exécution) d’une action.

La performativité du code évoque son pur potentiel opérationnel (le code fait agir la machine), en dehors de toute considérations sur l’inscription et la manière. Deux programmes écrits différemment pourraient ainsi avoir la même performativité (objectivement le même effet). La performativité suggère que le code source (les fichiers qui le composent) contrôle les opérations ; il assumerait totalement cette tâche jusqu’à se confondre avec ses propres conséquences : « Le logiciel ‹ joint le mot à un résultat, le verbe à l’action › »[^1], le calcul fait place au résultat, sans que l’on puisse savoir ce qui a été calculé ou comment.

[^1]: Wendy Hui Kyong Chun, On ‹Sourcery›, or Code as Fetish, 2008 cité par Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 (p.427)

principe SOLID

id : 20210206175831
dernière édition :
type : programmation
mots-clés : code

C’est un acronyme pour 5 recommandations sur la programmation orientée objet 🔗.

Single responsability

Éviter d’inscrire une God class, une classe à tout faire. Il faut réduire au maximum les fonctionnalités d’une classe pour qu’elle se cantonne à sa déclaration. Pour une classe Machine à café, mieux vaut découper le processus en différentes classes comme Chauffer l’eau ou Moudre le grain.

Open/closed

Un objet doit être ouvert à l’extension et fermé à la modification. C’est à dire que l’on va créer une classe qui, dès qu’elle sera jugée fiable, ne devra plus être modifiée. On fera éventuellement une extension de cette classe pour l’adapter à un cas particulier (par héritage).

Liskov substitution

Selon Barbara Liskov :

« Si q(x) est une propriété démontrable pour tout objet x de type T, alors q(y) est vraie pour tout objet y de type S tel que S est un sous-type de T. »

Expliqué autrement, la propriété q() est vraie tant que ses objets appartiennent à un type donné, ou bien à un de ses sous-types. Si le carré est un rectangle et si q(rectangle) est vrai, alors q(carré) est vrai.

Pour autant, pour une classe Carré, on se contentera d’un seul attribut pour définir à la fois sa longueur et sa largeur. Ce sont deux attributs nécessaires à une classe Rectangle qui ne peut donc hériter des propriétés de Carré.

Interface segregation

Dependency injection

Dans la continuité du premier principe, il ne faut pas hésiter à externaliser (décentraliser) des fonctionnalités dans d’autres classes pour finalement réunir leurs produits dans une classe qui fera le travail de traitement final.

principes de sécurité informatique

id : 20200619121419
dernière édition :
type : processus
mots-clés : informatique

Confidentialité

Seules les personnes autorisées peuvent avoir accès. Tout accès indésirable doit être empêché.

Intégrité

Les données doivent être celles que l'on attend, et ne doivent pas être altérées de façon fortuite, illicite ou malveillante.

Disponibilité

Le système doit fonctionner sans failles durant les plages d'utilisation prévues et garantir l'accès aux services et ressources installées avec le temps de réponse attendue.

Traçabilité

Garantie que les accès et tentatives d'accès sont tracés et que ces traces sont conservées et exploitables.

Authentification

L'identification est fondamentale pour gérer les accès aux espaces pertinents.

Non-répudiation

Personne ne doit pouvoir contester les opérations qu'il a réalisé dans le cadre de ses actions autorisées et ne doit pouvoir s'attribuer les actions d'un autre utilisateur

Source, vidéo et commentaires : https://www.youtube.com/watch?v=Ybp7ncdJlFM

principes du transcanal

id : 20200502111554
dernière édition :
type : undefined
mots-clés : scienceinformation

Le transcanal

On parle d’informatique ubiquitaire pour désigner les technologies ayant vocation à couvrir ce large éventail de protocoles et supports informationnels.

L‘information se déploie entre différents supports : entre le numérique et l‘analogique (« rapport proportionnel et continu entre l'information initiale et sa représentation »), sous différents formats, via différentes interfaces, avec différents éléments d‘interactions.

🔗 responsive

Cet ouvrage nécessite une architecture de l‘information permettant d‘articuler (en synergie) ces nombreux canaux et l’information qui doit leur parvenir depuis une même base de connaissance, par différents pipes.

Le contrôle que nous pouvons avoir de ces différents canaux varie, ainsi que le public d‘utilisateurs. Autant de paramètres à prendre en compte tout en considérant que la base sera nécessairement amenée à être portée par les internautes sur des plateformes qui n‘étaient pas initialement envisagées, comme par exemple lors du partage d‘un lien sur un nouveau réseau social.

5 principes du transcanal

Les deux architectes de l‘information Andrea Resmini et Luca Rosati notent les points d‘attention suivants pour concevoir un système d‘information transcanal dans leur livre Pervasive Information Archtecture. Ainsi, un tel système doit être

  • explorable : permettre aux utilisateurs, même novices, de faire leur propre chemin entre les différents supports : les « passes » doivent être subjectives, intuitives.
  • appropriable : l‘utilisateur doit pouvoir adapter son environnement, enregistrer des contenus qu‘il souhaite retrouver. Il y avoir une certaine persistance dans son utilisation.
  • cohérent : classer les contenus.
  • souple et robuste : les habitudes des utilisateurs évoluent et ils sollicitent la base de connaissances pour différentes raisons : d‘une même base on doit pouvoir mettre en place des chemins mobiles et adapter pour différents visualisations.
  • simple : on ne cherche pas à rendre la base de connaissance « plus simple », à limiter son contenu, à limiter les outils permettant d‘y accéder. On cherche à rendre « moins complexe », avec des outils d ›exploration adaptés, mais toujours en offrant le maximum de possibilités aux utilisateurs les plus expérimentés.
  • coordonné : « continuité et prolongement »

problème des logiciels de traitement de texte

id : 20200707161136
dernière édition :
type : processus
mots-clés : lectureecriture, typographie

🔗 application

Les logiciels de traitement de texte sont largement utilisés par les amateurs et professionnels de l’écriture. On liste ci-dessous certaines critiques à leur encontre qui s’appliquent notamment à ces logiciels qui, il faut bien en avoir conscience, reposent sur une histoire :

  • Word (Microsoft) ;
  • LibreOffice et OpenOffice Writer (open-source) ;
  • Pages (Apple) ;
  • Google Docs (Google).

Histoire

« Les premiers traitements de texte sont ainsi réalisés dans le cadre étroit de l’aide au développement de logiciels puisque leur première fonction est de documenter du code »[^2]

Les logiciels de traitement de texte vont ainsi être dédiés au code pendant une longue période. En parallèle, ils vont également permettre aux usagers d'imprimer des documents en proposant une interface WISIWIG et les différents drivers (logiciel de mise en route) pour la plupart des imprimantes du marché.

🔗 interfaces d'écriture

Plus tard, ces logiciels vont perdre leur support des langages de programmation, en même temps que leurs usagers.

Les outils d’écriture ne sont pas neutres

Choisir un logiciel pour écrire n’est pas anodin et a de nombreuses conséquences à court, moyen et long terme. En effet, utiliser les logiciels de traitement de texte, c’est se soumettre au « paradigme de l’imprimé »[^3].

🔗 paradigme de l’imprimé

« Nos outils d’écriture exercent un impact majeur sur la production des connaissances. En effet : 1. Ils influencent la structuration des contenus. 2. Ils définissent les critères d’accessibilité des contenus. 3. Ils déterminent la pérennité ou l’obsolescence des contenus. »[^1]

🔗 rapport aux objets techniques

Si tous les logiciels de traitement de texte n’ont pas leur code source fermé, ne sont pas liés à une multinationale, ne produisent pas des fichiers au format au mieux complexes, sinon opaques, il reste que ce sont des logiciels à l’utilisation parfois complexe produisant un résultat médiocre s’agissant de mise en page et de structure documentaire.

« Ils nous font en fait perdre beaucoup de temps : ils nous imposent de trop nombreuses interactions, qui causent des frictions chronophages ; et l’opacité de leur code nous empêche d’automatiser des processus de manière fiable »[^4]

Principe WYSIWYG

Tous les logiciels de traitement de texte fonctionnent sur le principe du WYSIWYG.

🔗 interfaces d'écriture

Perte de la source

🔗 architexte

« Cela détermine l’illusion d’une désintermédiation et d’une continuité entre la représentation à l’écran et le document final imprimé. En réalité cette illusion cache la situation inverse. Plutôt que rapprocher l’écrivain du document final en diminuant le nombre de médiations, l’approche de Word implique une multiplication de médiations invisibles à l’utilisateur mais structurantes sur le contenu »[^1]

Quand l’utilisateur voit son beau texte, il ne peut considérer le charabiat qu’il vient en réalité d’enregistrer : le code source de son texte (sa véritable essence désormais prisonnière) est soumise à l’interprétation d’une gamme retreinte de logiciels car encodé dans une architecture complexe, un XML plus ou moins lisible, plus ou moins enfouis selon les exports.

🔗 littératie numérique

« L’illusion de désintermédiation s’accompagne par ailleurs d’une illusion de littératie : Word donne l’impression que n’importe qui, sans compétences particulières, peut choisir un gabarit de page, définir ses marges, établir une police de caractères, etc., soit se faire éditeur au détriment de cinq siècles du savoir-faire éditorial et typographique de l’imprimé. »[^1]

« Cette idéologie de la ‹ solution › incarne les contradictions d’une production de ‹ nouveauté › dans un cadre économisé de toute part. »[^5]

Les logiciels de traitement de texte paraissent apporter toutes les solutions pour développer une documentation professionnelle en écrasant du même geste toute une chaîne métier quand les professionnels savent qu’il est préférable de passer par l’intermédiaire de certains outils spécialisés comme LaTeX (gratuit) ou des logiciels de PAO (Publication Assistée par Ordinateur).

[^1]: Marcello V.R, Nicolas Sauret, Antoine Fauchier, Margot Mellet, Écrire les SHS en environnement numérique. L’éditeur de texte Stylo, 2020 [^2]: Julien Dehut, En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation, 2018 [^3]: Arthur Perret, Matière à pensées : outils d’édition et médiation de la créativité, 2018 [^4]: Arthur Perret, Comment critiquer les technologies de l’information et de la communication ?, 2021 [^5]: Anthony Masure, Le design des programmes, 2014

processualité éditoriale

id : 20200722215106
dernière édition :
type : processus
mots-clés : lectureecriture

🔗 processus documentaire

🔗 édition numérique

La processualité éditoriale est l’application d’un règlement collectif d’édition numérique, un ensemble d’engagements, de contraintes, de priorités. C’est une organisation d’un espace éditorial permettant de légitimer des contenus par ses règles de production. C’est le processus qui est légitimant et l’objet final (par exemple un article) n’est pas légitimé par lui-même. Ces contenus sont conçus de telle manière à ce qu’ils aient avec du poids, une « autorité contextuelle »[^1], par le biais de leur relation au règlement (de la communauté) qui les a conçu.

🔗 espace

Ainsi, un utilisateur ne va pas chercher la légitimité propre de ces documents, objets, tant qu’ils sont dans cet espace auquel il a accordé sa confiance car il connaît les règles, relations, de la communauté.

Modèles

Les articles Wikipédia tiennent leur légitimité d’une processualité éditoriale dynamique : les règles (ton neutre, citer les sources… ) sont fondées par les pratiques, lesquelles évoluent, et rebouclent sur les règles, modifiées après concertation: « dépendance récursive des pratiques et des règles »[^1].

Les articles de revue scientifique tiennent leur légitimité d’une processualité éditoriale statique : la confiance des lecteurs tient à la stabilité des règles du comité de relecture.

[^1]: Marcello Vitali-Rosati, La fin de l’autorité ? Pour une philosophie politique du web.

processus de l’UX Design

id : 20200505210147
dernière édition :
type : processus
mots-clés : design

🔗 design

L’UX Design est un processus qui s’applique aux produits interactifs. Selon l’un de ses théoriciens, Don Norman, l’UX Design doit couvrir « tous les aspects de l’expérience d’une personne avec un système ». Il se décline en trois étapes :

  1. l’empathie : quelles sont les pratiques, besoins inassouvis, difficultés, valeurs des utilisateurs ?
  2. les méthodes de prototypage
  3. les méthodes d’évaluation

Enquêtes

On peut tenter de comprendre les utilisateurs (empathie) par différents moyens. Le mieux est de croiser ces enquêtes et d’y recourir de manière appropriée.

Les questionnaires permettent de collecter de nombreuses informations dans une large population. Toutefois, on récolte ce que les gens disent et non ce qu’ils font. Si cette méthode — quand elle est bien préparée — permet de dégrossir un domaine encore trop flou lors d’une phase d’étude. C’est aussi une faible source d’inspiration : les données extraites sont principalement quantitatives et déshumanisées.

Les entretiens permettent de discuter avec l’utilisateur sur ses habitudes, ses envies, ses difficultés et il permettent de l’observer en pleine action sur des prototypes, les produits concurrents. On veillera à garder des premières traces d’utilisation. Ils nécessitent donc que le projet soit suffisamment avancé, dans une phase de production et il n’est pas possible de massifier la démarche.

La récolte de traces d’utilisation permet de suivre l’utilisation d’un produit mis sur le marché, phase d’utilisation et de le mettre à jour en fonction. Il s’agit de résoudre les bugs, mais aussi de voir quelles sont les fonctionnalités les plus utilisées et de prioriser les maintenances. Les inconvénients sont les mêmes que pour les questionnaires.

🔗 traces numériques

Prototype

Un prototype doit entraîner des questions d’utilisation. Ce sont des matériaux de conception facile à modifier et souvent incomplets. On doit se permettre de tester, de se tromper, de recommencer.

Évaluation

L’évaluation permet de vérifier la qualité du produit tout au long du processus d’UX Design, dans le cadre d’un projet agile. Il existe deux types d’évaluation pour juger de l’utilité et de l’efficacité d’un objet technique. Il faut bien évidemment les croiser pour obtenir la meilleure évaluation :

  • analytique : analyse des propriétés de l’objet avec un soucis scientifique.
  • empirique : on observe un utilisateur (plus ou moins averti) et on en déduit l’usage et l’efficience de l’objet dans ce cadre.
    • Observation de terrain
    • Test A/B : Test comparatif entre plusieurs propositions d’interface : la version actuelle et la version innovante

Ces évaluations doivent reposer sur des critères et autres grilles de lecture (dites heurisitiques, dans le sens où elles mènent à trouver les problèmes).

Concerter autour du design

L’UX Design a différentes facettes auxquelles répondent différents corps de métier :

  • Fonction par l’ingénierie : usages pratiques
  • Sens par le design : signification des objets dans une culture donnée
  • Économie par le marketing : relation de production, de distribution et d’échange

Ainsi, lors de la conception d’un produit, toute la chaîne de production devrait se soucié de l’expérience utilisateur durant un processus itératif : un projet agile.

🔗 méthode des projets agiles

processus documentaire

id : 20200724173541
dernière édition :
type : documentation
mots-clés : scienceinformation

🔗 document 🔗 organisation d’un système d’information

Différentes vues sur la vie du document.

Circuit

La documentation est l’ensemble des techniques permettant le traitement permanent et systématique de documents (ou de données 🔗), incluant la collecte, le signalement, l’analyse, le stockage, la recherche, la diffusion de ceux-ci, pour l’information des usagers.

  • permanent : on envisage un traitement sur le long terme ;
  • systématique : on envisage un traitement polyvalent pour l’ensemble des documents ;
  • signalement : faire connaître l’existence du document.

On parle d’enregistrer un document (lui ajouter des métadonnées 🔗 permettant de le retrouver comme les tags) avant de l’inclure dans le système documentaire pour le conserver. C’est aussi durant ce processus que l’on va condenser l’information contenue dans le document (en faire un résumé, une visualisation, cartographie…).

🔗 outils de classement

Échelle

Paut Otlet distingue 7 étapes de classification de la connaissance humaine. Les 4 premières consistent à formaliser la connaissance et les 3 autres à la structurer en un système documentaire.

  1. Les choses : l’univers et les réalités ;
  2. Les intelligences : ceux qui peuvent penser les choses en les fragmentant ;
  3. La science : carder et coordonner les pensées particulières ;
  4. Les livres : diviser et fixer la connaissance ;
  5. La bibliographie : inventaire et catalogue des connaissances ;
  6. L’encyclopédie : concentration et classement ;
  7. La classification : science de l’organisation de la connaissance.

Transformation

Manuel Zacklad propose le modèle de circulation documentaire suivant pour éditer des documents numériques en profitant de leurs qualités 🔗. On distingue les notions de texte (« production sémantique ») et support et on propose de considérer dans ce processus des variantes (copies flexibles) d’un même document à différents temps de sa production.

  • Le stade de protodocument (document prototype) est neutre. Le document est alors libre de tout processus documentaire (n’est pas optimisé pour être re-trouvé, re-lu) et n’est pas formé (mise en page). Il s’agit à ce stade du simple résultat de la fusion texte-support (d’enregistrement).
  • Le stade de primodocument donne sa singularité (forme canonique) au document. Il possède alors une forme stable et des métadonnées 🔗 qui lui permettent de s’intégrer dans un système documentaire (indexation).
  • Le stade final de document réapproprié est l’adaptation d’un document aux préférences de l’utilisateur et à ses conditions de lecture, grâce aux dispositifs qu’il intègre.

Le processus se déroule en trois étapes :

  1. enregistrement : on fusionne du texte sur le support ;
  2. documentarisation 🔗 : on fragmente le protodocument pour considérer ses parties et ainsi travailler sa forme pour optimiser sa lecture et son intégration dans un système documentaire ;
  3. redocumentarisation : on adapte le document à un usager particulier.
flowchart

production_sémiotiques --> enregistrement
support --> enregistrement
enregistrement --> protodocument
systèmes_organisation_connaissances --> documentarisation
protodocument --> documentarisation --> primo_document
systèmes_organisation_connaissances --> redocumentarisation
primo_document --> redocumentarisation
redocumentarisation --> document_réapproprié
référence adaptation
protodocument neutre forme du document
primodocument canonique fragments du document
document réapproprié spécifique préférences usager

Qualités

« Les buts de la documentation organisée consistent à pouvoir offrir sur tout ordre de fait et de connaissances des informations :

  • Universelles quant à leur objet ;
  • Sûres et vraies ;
  • Complètes ;
  • Rapides [à trouver] ;
  • À jour ;
  • Faciles à obtenir ;
  • Réunies d’avance et prêtes à être communiquées ;
  • Mises à la disposition du plus grand nombre. »[^1]

[^1]: Paul Otlet, Traité de documentation, 1934

production de contenu web

id : 20200705112816
dernière édition :
type : processus
mots-clés : web, scienceinformation

La production de contenus est un processus de lecture et d’écriture. L’expression « agrégation/transsubstantiation » de Dominique Cardon traduit à merveille un geste en deux temps qui est celui du web dans un processus d'écriture web : rassembler (agréger) des contenus éparses (échange « pair à pair ») et valoriser leur contenu (substance) par combinaison (algorithmes, programmation).

On parle de lecture dans toute la mesure de la litteratie numérique. De même, on parle d’écriture dans le mesure où tout en informatique est texte, code, même les images.

🔗 littératie numérique

Hyperdocument

Les internautes « [produisent] du lien et du web »[^2], consécutivement. La production de contenu n'est qu'une (mise en) forme, une manière de disposer ce qui va réellement être exploité : les liens (hypertexte) faisant du contenu un hyperdocument.

« L’écriture peut être décomposée en deux actions distinctes et complémentaires : inscrire et structurer. Inscrire pour fixer des contenus. Structurer pour distinguer les éléments qui constituent ces contenus »[^3]

Valorisation

Le processus essentiellement double de la production de contenu web conduit nécessairement à la valorisation d’une base (plus ou moins définie et référencée), effet collatéral de la production (volontaire ou non) de liens.

🔗 valorisation de contenu numérique

Pair à pair

Le travail collaboratif, dit « pair à pair » (« peer to peer »).

« La dynamique des productions numériques a besoin de cette indétermination des fins pour remplir sa fonction expressive. Il lui faut s'insérer dans un dispositif qui, plutôt que le calcul, encourage la prolifération des échanges et l'endettement mutuel des internautes dans un système de réciprocité qui rend chacune de leurs productions interdépendantes les unes des autres »[^1] (p.60)

C'est cet « endettement mutuel », le fait de voir tant de créateurs soucieux de partager librement leurs réalisation qui va inciter d'autres bénévoles numériques.

« Calculer sa réputation détruit la valeur de la réputation et en altère l'expérience. En partageant leurs passions, les internautes s'adressent mutuellement des signes de reconnaissance et d'approbations mutuelles. Ils ne sont jamais quittes les uns des autres et trament entre eux des chaînes d'appréciations et de jugements qui doivent constamment être renouvelés. »[^1] (p.62)

Comptage

L'internaute qui partage n'est pas dans le calcul, mais dans un agir, souhaitant volontairement ne pas regarder ses arrières, ce qui serait mal vu. Il est dans la création bornée et ne peut se vanter de son œuvre : ce serait montrer qu'il est intéressé. Il y a ensuite la possibilité de faire valoir ce travail — s'en est un — auprès des autres internautes grâce aux nombreuses plateformes permettant d’agréger les contenus et les contributions dont elles dépendent.

Il faut toutefois nuancer cette altruisme en évoquant une économie de la réputation, un calcul exprimé en statistiques largement visible sur les profils des internautes.

Digital labor

🔗 digital labor

La valorisation de contenu tend de plus en plus à être sous-traité à des individus par le biais de plateformes de la politique du digital labor. Dans une certaine mesure, il faudrait arrêter de parler de « contribution » et plutôt d’« extraction » quand il s’agit d’exploiter le contenu mis en ligne par les internautes, parfois non intentionnellement (traces numériques).

🔗 traces numériques

« Le digital labor reflète cette posture dans la mesure où il relativise l'exaltation héroïque des amateurs et des fans passionnés, et y oppose une vision où l'ethos du don complète dans un équilibre instable les éléments utilitaires ou d'intérêt économique. C'est que la notion de digital labor refuse de faire l'impasse sur les phénomènes de captation de la valeur par le capitalisme des plates-formes numériques, sur les dynamiques de récupération marchande des flux de générosité par les entreprises du Web, qui ont prospéré durant ces mêmes années en comptant sur la libéralité des utilisateurs et sur leur envie de participation. Il ne passe pas à côté des formes de paupérisation de toute une catégorie de producteurs de contenus multimédias, inscrits dans une relation de travail non rémunérée, éclipsée par la rhétorique de « l'envie de contribution »[^2] (p.6)

[^1]: Antonio Casili, Dominique Cardon, Qu’est-ce que le digital labor ?, 2015 [^2]: Antonio Casili, Qu'est ce que le gigital Labor : Travail, technologies et conflictualités, 2015 [^3]: Antoine Fauchié, Vers un système modulaire de publication : éditer avec le numérique, 2019

programmation déclarative

id : 20210123212346
dernière édition :
type : programmation
mots-clés : informatique, code

C’est une famille de paradigmes de programmation 🔗 consistant à former des composants logiciels indépendants du contexte d’appel. Ils n’ont pas d’état interne et respectent ainsi la transparence référentielle 🔗.

On évite ainsi les effets de bord 🔗. On garde un code efficace et facile à documenter, puisque chaque composant a une utilité précise. Le coût d’entrée dans le code est plus important à cause de la particularité des opérations, ad hoc.

Si certains langages comme le Haskell fonctionnent exclusivement selon cette logique. Pour les autres langages, il est possible de se discipliner pour limiter au maximum le nombre de composant ayant un état interne.

programmation fonctionnelle

id : 20201222163154
dernière édition :
type : programmation
mots-clés : code

🔗 paradigmes de programmation

Le programmation fonctionnelle est un paradigme de programmation déclaratif 🔗 : « la logique du programme est exprimée sans décrire explicitement le flux de contrôle »[^1]. Les différents principes d’écriture qu’il prescrit rendent un code plus plus concis, plus prévisible et plus facile à tester[^1].

Flot de contrôle

Avec les fonctions pures 🔗 on contrôle le traitement des données pour le rendre prédictible et déterministe[^2]. Ainsi, on limite les bugs en facilitant le suivi du flot de contrôle 🔗. L’appel en cascade de ces fonctions, très régulières, sans changement d’état (comme l’on pourrait l’observer en programmation orienté objet 🔗) simplifie à l’extrême les opérations mathématiques.

Immutabilité

On va faire en sorte de bien marquer les éventuels changements de valeurs des variables.

🔗 la portée des variables

// mutation
let array = ['Jean', 'Marc']
array.push('Julie') // ['Jean', 'Marc', 'Julie']
// immutabilité
const array = ['Jean', 'Marc']
const newArray = array.concat('Julie') // ['Jean', 'Marc', 'Julie']

[^1]: Eric Elliott, Master the JavaScript Interview: What is Functional Programming?, 2017 [^2]: Alexandre Duarte, Programmation fonctionnelle #1: Les 3 grands principes, 2018

programmation graphique

id : 20201127165909
dernière édition :
type : modélisation

La programmation graphique (ou programmation visuelle) permet de faciliter la compréhension et/ou l’écriture d’un programme 🔗 pour une personne n’étant pas habituée à la programmation textuelle. L’un des environnements de développement les plus connus proposant un tel langage est Scratch.

« La ‹ programmation visuelle › désigne tout système qui permet à l’utilisateur de spécifier un programme de manière bidimensionnelle (ou plus). […] les langages textuels conventionnels ne sont pas considérés comme bidimensionnels puisque les compilateurs ou les interprètes les traitent comme de longs flux unidimensionnels »[^2] (p.98) 🔗

Interface

Il s’agit de placer des éléments graphiques (souvent des blocs) dans un espace. Selon leur forme, couleur, texte, ces éléments suggèrent leurs opérations, mais aussi leurs combinaisons (formant système combinatoire 🔗). Il s’agit souvent de pièces de puzzle à emboîter d’après des repères visuels ; les extrémités autorisent ou non la combinaison. Ce sont autant de structures de contrôle 🔗 qui permettent de faire circuler l’information. Des champs internes permettent de préciser leur valeur.

Utilisation

Brad Myers[^2] écrit qu’il est possible de classer les outils de programmation graphique selon deux axes :

  • illustration du code (instruction + données) OU l’algorithme
  • dynamique OU statiques

Il est en effet possible de présenter le code source du programme avec une aide visuelle pour se repérer. C’est différent d’une présentation ou seule la logique (abstraite 🔗, imagée) de programmation est présentée.

« Par exemple, l’animation d’un algorithme d’une routine de tri peut montrer les données sous forme de lignes de différentes hauteurs, et l’échange de deux éléments peut être représenté par une animation fluide du déplacement des lignes. L’opération de ‹ swap › n’est pas forcément explicite dans le code »[^2] (p.99)

Les visualisations dynamiques permettent de saisie le sens du programme grâce à l’animation de l’interface et non simplement avec des instantanés.

Avantages

L’utilisateur n’a pas besoin de se soucier du langages de programmation utilisé en arrière plan, de l’environnement de développement 🔗 (donc architecture limitée), de ses mots-clés et de sa syntaxe 🔗 :

« Un autre avantage majeur de la PV [programmation visuelle] repose sur le fait qu’elle permet d’abstraire l’utilisateur des problèmes de syntaxe liés à l’utilisation d’un langage de programmation. Cela grâce au fait que les éléments graphiques manipulés ne représentent que des instructions valides. »[^1]

Limites

Même si le niveau d’abstraction 🔗 est très important, il reste nécessaire pour l’utilisateur de comprendre les concepts de la programmation, et notamment les structures de contrôle comme les conditionnels, boucles… et l’encapsulation 🔗.

« outre la taille nécessaire à sa représentation, un diagramme composé de nombreux éléments graphiques ne peut pas vraiment être explicite, ni intuitif, et donc compréhensible pour un non initié. De plus, même s’il est possible de réduire les éléments graphiques à des icônes ou d’utiliser des briques de programmation définies récursivement, la taille de l’écran reste une limitation incontournable »[^1]

[^1]: Fabien Michel, Jacques Ferber, Pierre-Alain Laur, Aleman Florian, Programmation situationnelle: programmation visuelle de comportements agents pour non informaticiens, 2010 [^2]: Brad Myers, Taxonomies of Visual Programming and Program Visualization, 1990

programmation impérative

id : 20210123214450
dernière édition :
type : programmation
mots-clés : informatique, code

C’est une famille de paradigmes de programmation 🔗 centrés sur la modélisation 🔗 de l’état de leurs composants. Il s’agit principalement de créer des objets 🔗 ; leur héritage permet de prescrire précisément leurs évolutions, leurs changements d’état.

La rigueur de la modélisation permet non seulement de monter en abstraction 🔗 (simplifiant les opérations), mais aussi de contrôler strictement les affectations, de garantir l’intégrité des données et la stabilité des liaisons internes. Il en résulte des procédures compliquées par l’encapsulation 🔗.

Ces paradigme reposent principalement sur la programmation orientée objet 🔗 et tous les langages ne s’y prêtent donc pas.

programmation lettrée

id : 20200914211839
dernière édition :
type : programmation
mots-clés : code

🔗 paradigmes de programmation

La programmation lettrée (literate programming) est un paradigme de programmation très verbeux. Il engage le développeur à expliciter son programme, sa structure, sa genèse, à opérer une médiation entre son programme et ses pairs. Ainsi, il assure la relecture de son travail et approfondis la sienne dans le même temps. Le code gagne en qualité.

« Je crois que le temps est venu pour une documentation significativement meilleure des programmes, et que la meilleure façon d’y parvenir est de considérer les programmes comme des œuvres littéraires »[^1] (p.1)

Code comme documentation

Le code source 🔗 devient une documentation 🔗 par lui-même et décrit précisément et successivement les étapes de résolution d’un problème grâce à la documentation du code 🔗. Contrairement à l’index d’une API 🔗, qui document fonction par fonction, « le texte est au premier plan, et c’est lui qui impose la structure du programme, pas le langage machine »[^2].

Le but n’est pas simplement de commenter le code 🔗 ou d’écrire du code contenant de la documentation. On va écrire de la documentation contenant du code. On doit obtenir un programme destiné à l’humain dont le code peut-être extrait et déplacé avec des outils adaptés pour ensuite être exécuté.

Pour cela on va découper le programme en sections dont l’ordre d’affichage est commandé par une logique globale, une démarche d’explication, et non simplement une logique fonctionnelle. Chaque section doit comporter au moins un de ces trois éléments : documentation, définition et/ou code. On empile ensuite ces sections dans des fichiers et éventuels carnets, comme des carnet de programmation 🔗 (essaies computationnels).

Le développeur se force ainsi à expliquer en permanence sa démarche, à structurer son code comme il est logique de le penser. Il rend ainsi les erreurs de conception plus évidentes et donne une vue d’ensemble sur le code, car toujours dans le prolongement d’une logique qu’il a éprouvé en la mettant en œuvre puis en l’expliquant.

« Mes programmes ne sont pas seulement mieux expliqués que jamais auparavant ; ils sont aussi meilleurs, car la nouvelle méthodologie m’encourage à faire un meilleur travail »[^1] (p.1)

On explicitera les éléments (critiques, analytiques) suivants :

  • l’architecture et les décisions de conception
  • les motivations liées à l’ajout (effectif ou non) d’une fonctionnalité

Paradigme de programmation

🔗 paradigmes de programmation

« j’impose un engagement moral à tous ceux qui entendent le terme ; sûrement personne ne veut admettre avoir écrit un programme analphabète »[^1] (p.1)

Ce paradigme est utile pour les programmes de toute taille. Il peut être appliqué avec langages de haut niveau (des strates des langages de programmation 🔗), quand il est possible de recourir au moins partiellement aux langages naturelles pour nommer les structures de contrôle et faire des commentaires.

Dans le cadre de la programmation lettrée, on s’oblige à soigner le plus justemment la documentation de son code 🔗, à nommer judicieusement chaque variable 🔗, à soigner le style d’écriture et de mise en forme de nos commentaires de code 🔗.

« Changons notre attitude traditionnelle envers la construction des programmes : au lieu de considérer que notre tâche principale est de dire à un ordinateur ce qu’il doit faire, appliquons-nous plutôt à expliquer à des êtres humains ce que nous voulons que l’ordinateur fasse. Celui qui pratique la programmation lettrée peut être vu comme un essayiste, dont la principale préoccupation est l’exposition et l’excellence du style. Un tel auteur choisit avec soin, le dictionnaire [ou thesaurus] à la main, les noms des variables et explique la signification de chacune d’entre elles. Il ou elle s’efforce d’obtenir un programme compréhensible parce que ses concepts ont été introduits dans un ordre qui convient le mieux à la compréhension humaine, en utilisant un mélange de méthodes formelles et informelles qui se renforcent mutuellement. »[^1] (p.1)

Règles d’écriture du code

Liste de critères pour une utilisation efficace de la programmation lettrée[^3] :

  • Le code et sa documentation proviennent des mêmes fichiers ;
  • Le code et sa documentation sont maillés autour d’une même instruction ;
  • Le programme doit avoir des subdivisions logiques ;
  • Le système doit être présenté dans un ordre basé sur des considérations logiques plutôt que sur des contraintes syntaxiques ;
  • La documentation devrait inclure un examen des solutions alternatives et devrait suggérer des problèmes de maintenance et des extensions futures ;
  • La documentation doit comprendre une description du problème et de sa solution, éventuellement avec des démonstrations logiques et/ou graphiques ;
  • On doit bien pouvoir distinguer à la lecture les mots-clés et variables.

Application

L’application du paradigme de la programmation lettrée nécessite un dispositif bilingue[^1] (p.2), mêlant un langage de programmation 🔗 et un langage dédié à la mise en page (comme TEX ou Troff). Ils sont incrits dans les mêmes fichiers (« WEB file »[^1], p.2), lesquels sont ensuite scannés pour y opérer deux processus d’extraction de code executable, les enregistrer dans deux autres fichiers et enfin les executer. Le tout nécessite la mise en place d’une chaîne d’execution de programmes compatibles, permettant d’extraire les langages puis de les executer.

file.web (JavaScript + TEX)
↘ file.js
↘ file.tex

« Le programme et sa documentation sont tous deux générés à partir de la même source, ils sont donc cohérents entre eux »[^1] (p.2)

Modération

Le projet est très ambitieux et Donald Knuth lui-même indique « En fait, mon enthousiasme est si grand que je dois avertir le lecteur d’écarter une grande partie de ce que je vais dire comme les divagations d’un fanatique qui pense qu’il vient de voir une grande lumière ».

La programmation est une activité personnelle et lui imposer un paradigme aussi lourd peut perturber le travail de confrères bien que Donald Knuth y ait trouvé une nouvelle méthode de travail qui l’inspire.

[^1]: Donald Knuth, Literate Programming, 1983 [^2]: Raphaël Lemaire, Litterate programming, 2017 [^3]: Bart Childs, Literate Programming, A Practitioner’s View, 1992

programmation orientée agent

id : 20201122095822
dernière édition :
type : programmation
mots-clés : code

🔗 paradigmes de programmation 🔗 programmation orientée objet

Le paradigme de la programmation orientée agent est une spécialisation du paradigme orienté objet : « les agents sont les éléments centraux du langage, de la même façon que les objets sont centraux pour les langages orientés objets »[^1].

🔗 système multi-agent

Les objets deviennent des agents, des entités pourvues de notions cognitives, capable d’interagir entre elles et avec un environnement. C’est une interaction sociale (système multi-agents) basée sur des messages type « informer, demander, offrir, accepter, rejeter »[^1].

puisque les agents sont autonomes et dotés de capacités mentales, ils ont la liberté de décider s'ils vont ou non exécuter l'action spécifiée dans le message. Par contraste, un objet recevant un message va toujours exécuter l'action spécifiée dans le message.[^1]

Interaction

🔗 objet informatique

La programmation orientée objet permet d’envoyer une réponse selon la méthode exécutée pour un objet, la programmation orientée agent oblige en plus le développeur

  • à étendre la définition de l’objet pour lui donner des obligations, croyances ;
  • à typer les messages, leur donner une valeur qui puisse être interprétée entre deux objets en communication ;
  • à vérifier les échanges et opération internes pour laisser l’objet d’exprimer sur sa bonne intégrité et sur la justesse des transmissions de ses pairs.

En effet, on trouve aux agents certaines caractéristiques[^1] que n’ont pas les objets :

  • les agents sont autonomes alors que les objets ne le sont pas : un agent va décider par son propre processus de décision s'il exécute ou non une action requise ;
  • les agents ont un objectif défini et anticipe donc les appels ;
  • les agents sont capable d’un comportement social (complexe) comme pour la coopération, compétition, négociation avec d’autres agents

Contrôle

Un agent possèdes les entités suivantes :

  • croyances
  • objectifs
  • ressources
  • capacités/compétences
  • obligations

Pour actionner un agent dont on a bien définit les croyances initiales, on passe par les étapes suivantes :

  1. lire les messages reçus
  2. actualiser les croyances en fonction de ces messages
  3. appliquer les obligations valides en fonction de ces messages
  4. appliquer les obligations courantes
    • immédiatement si elle sont privées
    • selon la condition mentale de l’agent si elles sont communicatives

[^1]: Adina Florea, Daniel Kayser, Stefan Pentiuc, Agents intelligents, 2002

programmation orientée aspects

id : 20201227185824
dernière édition :
type : programmation
mots-clés : code

🔗 paradigmes de programmation

La programmation orientée aspects ne vient pas remplacé d’autres paradigmes, mais au contraire les compléter sur différents points transverses comme la gestion de modules 🔗. Ce peut être des modules de connexion, d’enregistrement des erreurs, de test des requêtes.

Ces modules sont greffés au programme sans être intégrés au sein des fonctions afin de pouvoir les ajouter, modifier ou retirer sans avoir à rentrer dans le code source.

https://www.jmdoudoux.fr/java/dej/chap-aop.htm

https://www.bart-konieczny.com/fr/spring-par-pratique/concepts-base/programmation-orientee-aspect

programmation orientée objet

id : 20200522122316
dernière édition :
type : programmation
mots-clés : code

La programmation orienté objet (POO) est un paradigme de programmation 🔗 impératif 🔗. Son intérêt est de pouvoir l’approcher aussi bien dans l’inscription du code du code que dans l’architecture logicielle, notamment par le biais de modélisations comme l’UML 🔗.

La programmation orienté objet n’est pas adaptée à toutes les situations, à tous les projets, dans la mesure où il n’est pas possible d’appliquer ce paradigme à tous les langages de programmation et qu’il s’agit d’une lourde charge conceptuelle (tant pour les humains concepteurs que pour les machines exécutrices), inutile pour les programmes légers.

L’objet

Un objet 🔗 est une structure de contrôle 🔗 représentant un concept, une idée ou toute entité du monde physique modélisée 🔗]], exprimé dans un langage de programmation. On peut ainsi créer une personne, une gourde, une maison, dans sa substance et dans son agir : ce qu’il est et ce qu’il peut faire (ou ce que l’on peut en faire).

L’objet encapsule deux autres types de variables 🔗 liées par un champ sémantique :

  • attributs : variables stockant les valeurs de l’objet (ce qu’il est) ;
  • méthodes : fonctions permettant définir les comportements de l’objet, internes ou externes (ce qu’il peut faire ou ce que l’on peut en faire).

Par exemple, un objet personne pourra avoir les attributs age, taille, nom et les méthodes marcher, parler, porter. Ces attributs évoluent au cours de l’exécution et on dit alors modifier l’état courant de l’objet.

Utilité

L’objectif est de faire interagir des groupes d’objets pour former un système, de mettre en place un système combinatoire 🔗 de modules 🔗. On définit le potentiel et les limites des unités pour les réunir dans une organisation très stricte et abstraite 🔗. On évite la « programmation spaghetti » et l’accumulation de la dette technique 🔗 en systématisant les contrôles internes.

« Les principales motivations de toutes les méthodologies orientées objet existantes sont aussi vieilles que le génie logiciel lui-même : l’abstraction et la séparation des préoccupations comme un moyen de faire face à la complexité. Ce qui est plus spécifique à l’orientation objet est la transition en douceur entre les phases, en particulier entre l’analyse et la conception »[^1] (p.1)

Principes

La programmation orienté objet a trois grands principes :

  • l’encapsulation 🔗 : la circulation des données au sein de l’objet est plus ou moins hermétique, il est possible d’en limiter l’accès pour assurer l’intégrité et la sécurité des données ;
  • l’héritage : un objet se décline selon une matrice initiale (dont il hérite des caractéristiques) pouvant elle-même être décliné d’une autre matrice ;
  • le polymorphisme : l’espace de nom au sein des objets est hermétique permettant ainsi
    • d’avoir des fonctions de même nom et usage d’un objet à l’autre,
    • d’avoir des fonctions de même nom dans les paramètres peuvent varier,
    • d’appeler des fonctions n’étant pas intégrées à l’objet, mais à son parent.

Ainsi, un objet est une structure de contrôle hermétique, héritée et polymorphique. La programmation objet permet de créer des entités à la volée répondant toutes à ces principes, par exemple une foule de personnes, un pack de gourdes, une zone résidentielle ; toutes ces entités seront différentes (polymorphisme), mais hériteront des mêmes attributs et méthodes qu’il sera possible d’utiliser individuellement (encapsulation).

Encapsulation du traitement

On cherche la sécurité et l’intégrité des données par l’encapsulation 🔗. On met en place au sein des classes de nombreux barrages afin de contrôler les échanges.

L’instance d’une classe débute généralement par la configuration de son constructeur. C’est lui qui va prendre en paramètre les valeurs de l’objet lors de son instance pour le « remplir ». Le constructeur va lui faire appel à des méthodes spéciales appelées « ascenseurs » (setters) qui vont affecter les valeurs reçues aux attributs de l’objet tant en sécurisant l’opération (imposer un typage, un domaine de valeur). La valeur de ces attributs pourra ensuite ou non être extraite de l’objet via les méthodes appelées « mutateurs » (getters) : elles pourront appeler et transformer la valeur d’un attribut avant de la transmettre.

Les attributs sont persistants durant toute l’instance et propres à chaque objet. Les méthodes sont des unités fonctionnelles dont les entrées et sorties se font en amont ou en aval des ces mêmes attributs. Dans ce domaine hermétique de l’objet il est possible de combiner et recombiner les méthodes, de faire circuler les valeurs entre différents objets sans risquer des fuites ou des incompatibilités.

Instance

🔗 instance informatique

Pour créer un objet, il y a deux types de matrices :

  • la classe : « moule fixe » à objet : elle reste figé pendant la procédure et représente une définition abstraite de l’objet (elle le moule sans que l’objet n’incarne la classe) ;
  • le prototype : « moule modulaire » : les objets sont systématiquement le prolongement d’autres objets et il est possible à tout moment de la procédure de modifier la forme d’un objet (lui créer un prototype) et d’utiliser cette nouvelle forme (héritage dynamique) pour créer d’autres objets (chaîne de prototypage).

🔗 instance informatique

[^1]: Lionel Briand, Software documentation: how much is enough?, 2003

programmation utilisateur

id : 20210123204800
dernière édition :
type : programmation
mots-clés : informatique

La programmation utilisateur désigne tous les processus qui permettent aux usagers de l’informatique n’étant pas développeurs de mettre en place des algorithmes 🔗.

Il existe plusieurs interfaces 🔗 qui peuvent faciliter ce processus comme un tableur (permettant d’enregistre des formules), une table de programmation graphique 🔗. Ils permettent de mettre en place facilement des variables, conditionnelles pour réaliser des calculs, de la validation de données.

Il existe aussi les scripts 🔗 : une liste d’instructions à répéter à la chaîne à l’activation. Ces instructions peuvent être saisies manuellement avec des liste déroulantes, des champs avec des termes logiques (et, ou). Dans certains logiciels il y a la possibilité de déclencher un enregistrement durant lequel l’utilisateur peut mimer ces actions alors ajoutées à la liste.

Certains formats de données facilitent également les enregistrements pour les utilisateurs, comme le YAML.

🔗 sérialisation des données

programme

id : 20200808143420
dernière édition :
type : programmation
mots-clés : informatique

Un programme est l’implémentation 🔗 d’un ensemble d’instructions pouvant être considéré comme une unité (réponse à un usage, unité de l’arborescence…) et prescrivant un comportement à un système.

« Ce qui va différencier l’algorithme du programme, c’est que l’algorithme est exprimé dans un langage générique, indépendant d’un langage de programmation particulier. Un programme, comme son nom l’indique, est retranscrit dans un langage de programmation particulier »[^1]

Il est donc possible d’écrire un même algorithme dans plusieurs langages, selon plusieurs paradigmes, différentes syntaxes, pour un même effet, avec les mêmes données.

Dans sa thèse, Anthony Masure rapporte une étymologie :

« ‹ Programme › apparaît dans le dictionnaire autour de 1680. Dérivé du grec programma, de pro, ‹ avant › et gramma, ‹ ce qui est écrit ›, programme peut alors se comprendre littéralement comme ‹ ce qui est écrit à l’avance › »[^1]

Le terme désigne une série d’actions prévues dans une chronologie. Le domaine spatiotemporel est en effet une notion fondamentale en programmation comme l’explique Bruno Bachimont :

« le programme permet de spécifier un parcours systématique : l’exécution du programme n’est alors que le déploiement temporel de la structure spatiale symbolique qu’est le programme »[^2]

En d’autres termes, le programme est une série d’instructions inscrites sur un support (domaine spatial - structure du programme 🔗) et son exécution consiste à les acter successivement (domaine temporel - 🔗). On peut parler de « chronotopie de processus »[^3].

Écriture

🔗 inscription computationnelle

« Le programme se pense alors à la fois du côté de ce qui précède l’écriture (ce que la machine pourra inscrire dans le monde), et aussi du côté de ce qui est mis en place pour produire un effet déterminé »[^1]

On ne peut voir le résultat de l’exécution du programme avant d’avoir terminé l’inscription du code et sa compilation/interprétation.

[^1]: Anthony Masure, Le design des programmes, 2014 [^2]: Bruno Bachimont, Signes formels et computation numérique : entre intuition et formalisme, 2004 [^3]: Louis-Olivier Brassard, Médium rhétorique, 2020

qualités de l’écriture numérique

id : 20200606201922
dernière édition :
type : inscription
mots-clés : scienceinformation

On reconnaît cinq qualités[^2] à l'écriture numérique, une « écriture réticulée »[^1] :

  • manipulabilité : application de règles de manipulation automatiques ;
  • abstraction 🔗 : modèles formels interchangeables pour un fond (contenu) abstrait ;
  • adressabilité : le numérique permet d'indexer et d’adresser le contenu ;
  • universalité : le numérique encode tous les contenus sans limite formelle ;
  • clonabilité : le numérique permet de produire de multiples instances identiques d'un contenu.

« Le texte devient alors une entité fluidifiée, susceptible de revêtir de multiples apparences au gré des réceptacles. »[^3]

Forme canonique

Depuis une forme canonique du fichier, « celle qui fait référence et qui établit conventionnellement son objectivité »[^4], il est possible de le visualiser de différentes manières, ne serait-ce qu’entre les vues 🔗 d’édition et de lecture. Afficher le code source d’un fichier (ex : visualiser le XML) c’est visualiser sa forme canonique.

[^1]: Éric Guichard, Les humanités numériques n’existent pas, 2019 [^2]: Wikipedia, Écriture numérique [^3]: Anthony Masure, Le design des programmes, 2014 [^4]: Stéphane Crozat et Bruno Bachimont, Réinterroger les structures documentaires : de la numérisation à l’informatisation, 2004

rapport aux objets techniques

id : 20200709104849
dernière édition :
type : undefined
mots-clés : design

Gilbert Simondon a entrepris une étude sociale de la technique, de notre rapport à ces objets. On peut transposer les remarques suivantes à tout objet technique, aux logiciels…

Aliénation

Gilbert Simondon évoque largement sur la relation profonde entre un « opérateur » et un objet technique :

« L’œuvre domestique l’opérateur par retour d’efficience quand elle émane d’un opérateur ou d’un geste opératoire asservi : il y a relation transductive et causalité récurrente dans le système réverbérant constitué par l’opérateur, l’œuvre et l’ensemble des réalités médiatrices intermédiaires entre l’homme opérateur et l’objet produit »[^1]

« La mauvaise reconnaissance de la technique induit notamment une aliénation du monde contemporain »[^2]

Culturel

Notre rapport aux objets techniques est principalement culturel. Gilbert Simondon prend l’exemple de la voiture. La forme de cet objet technique pourrait être conditionnée pour être un maximum aérodynamique, hors « des constructeurs puristes en technologie ont parfois déplu à la clientèle pour avoir recherché un aérodynamisme réel et non l’image stéréotypée de la ‹ forme aérodynamique › »[^1]. Ainsi l’objet technique est largement influencé non pas par une recherche de l’efficience, mais pour sa correspondance à l’« archétype social »[^1].

Voile

Un « voile » sur les objets techniques « maintient la séparation entre le sacré et le profane »[^1], soit entre l’aspect technique qui doit disparaître et l’aspect culturel associé qu’il faut montrer.

Il s’agit de distinguer

  • le phanérotechnique (technique visible) du cryptotechnique (technique invisible)
  • la technophanie (« manifestation du pouvoir de rayonnement et de communication des objets techniques »[^3]) de la technologie

C’est par « dédoublement » de l’objet technique (superposition de couches) que l’on va cacher le fonctionnement de l’objet technique.

« Le propre de la technique c’est quand elle est efficace, efficiente, elle s’efface devant ce qu’elle permet et donc on a tendance à l’oublier. D’où des gestes philosophiques qui consistent à vouloir penser cet oubli et remettre au devant de la scène ces médiations technologiques qui se sont effacées devant leur succès »

[^1]: Gilbert Simondon, Sur la technique, 2014 [^2]: Antoine Fauchié, Vers un système modulaire de publication : éditer avec le numérique, 2019 [^3]: Xavier Guchet, Pour un humanisme technologique, 2010

rapport humain-machine

id : 20210115183034
dernière édition :
type : processus
mots-clés : scienceinformation

« Il n’y a pas d’interactivité entre l’humain et la machine, puisque la machine n’agit pas »[^1]

Elle « fonctionne ». Elle n’est ni consciente, ni autonome. La perception, l’intelligence ou encore la mémoire des machines sont autant d’analogies.

[^1]: Cléo Collomb, Faire compter les machines, 2017

recherche dans les fichiers de code

id : 20211015174810
dernière édition :
type : inscription

La recherche dans les fichiers de code (comme pour les autres fichiers de texte brut 🔗) passe principalement par les expressions régulières. C’est une technique efficace dans la mesure où

  • la base des mots inscrits est d’une part limitée par le langage de de programmation 🔗 et d’autre part par les développeurs, tenus à leur nomenclature 🔗 ;
  • l’inscription du code 🔗 est normée, permettant d’affiner la recherche avec des critères commes les tabulations, les fins ou débuts de ligne.

Les développeurs et les EDI 🔗 utilisent cette méthode principalement pour retrouver les fonctions et classes, structures de contrôle 🔗 majeures. Toutefois, pour des requêtes portant sur des expressions arbitraires comme le nom des variables 🔗, la requête « peut produire un volume considérable de données de sortie, dont la plupart ne contiendra pas de référence à la variable »[^1] (p.4).

Il manque à ces « recherches plein texte » la sémantique. C’est paradoxal puisque ce sont les expressions régulières qui permettent d’attribuer du sens à certaines chaînes de caractère, via le parser du langage de de programmation 🔗. Il nous faudrait donc un outil, comme les EDI 🔗, capable d’interpréter/compiler 🔗 le code avant de pouvoir y effectuer des recherches. Il est donc nécessaire de passer par des formulaires, de disposer de plusieurs champs pour pouvoir jouer sur plusieurs variables de recherche[^1] (p.4).

« Le principal inconvénient de la recherche est qu’il est difficile d’obtenir une vue d’ensemble de l’espace d’information »[^1] (p.4)

[^1]: Susan Elliott Sim, Browsing and searching software architectures, 1999

refactoring, revue de code

id : 20210109140006
dernière édition :
type : programmation
mots-clés : code

Le refactoring (ou « réusinage de code », « remaniement de code ») consiste à retravailler un code source sans ajouter de fonctionnalité ou résoudre de bug. Il s’agit d’améliorer la lisibilité du code, de soigner vocabulaire 🔗, la présentation, la documentation du code 🔗. On facilite ainsi la maintenance 🔗 du programme.

La revue de code est en général effectuée par un responsable technique, garant du « bon code » 🔗, capable de le relire et d’y repérer d’éventuels défauts.

En effet, à force d’ajouts et de retours pour corrections des bugs, avec parfois différentes habitudes de développement qui se superposent, il est nécessaire de revenir régulièrement vérifier l’inscription du code pour

  • le remettre aux normes, selon la convention de développement 🔗 ;
  • supprimer les redondances et le code mort (variables 🔗 sans appel ou bien suspendues) ;
  • simplifier la lecture des algorithmes.

On peut distinguer ces différents niveaux dans le réusinage. À partir du deuxième, il faudra impérativement effectuer des tests de validation :

  1. Modifier la présentation du code source, soit l’ordre des instructions, l’indentation, les sauts de ligne ;
  2. Simplifier les algorithmes ;
  3. Relocalisation d’une instruction dans une autre structure de contrôle 🔗 ;
  4. Refonte de la conception, soit le remaniement de plusieurs composants.

Avec le versionnement

Il n’est jamais bon de laisser du code qui pourrait servir un jour. Mieux vaut versionner 🔗 le code et supprimer ces inscriptions ; on pourra toujours revenir sur une version précédente pour les retrouver.

J’utilise souvent l’inteface graphique de versionnement 🔗 pour afficher uniquement le code qui a été modifié et ainsi revoir rapidement à la fin d’une étape de travail la qualité de ce que j’ajoute avant de commit.

règles typographiques

id : 20200621094836
dernière édition :
type : inscription
mots-clés : typographie

🔗 typographie

On parle d’orthotypographie pour la corrections typographique. C’est un mélange de correction d’orthographe et de typographie.

Hauteur de caractère

On se base de manière générale sur l'échelle suivante de taille de caractère afin de garder une hauteur de lettres suffisamment différente entre deux paragraphes d'une échelle différente. La différence minimum de hauteur de caractère recommandée entre deux échelle est de 120%.

9, 10, 11, 12, 14, 18, 24, 36, 48, 64, 72, 96, 144, 288

Longueur de ligne

La longueur de ligne idéale est entre 55 et 60 caractères (le maximum), soit une longueur environs égale à 30 fois la hauteur des caractères : si la hauteur de caractères est de 14 pixels, la ligne devrait au maximum faire 420 pixels de long : 14 x 30 = 420.

Interligne

Entre deux lignes, il est recommandé d'avoir un interligne d'au moins 150% par rapport à la taille des caractères.

Grille

Il est important de considérer une grille dans les travaux typographique, des lignes entre lesquelles vont se glisser les lettres quelque soit leur taille. Cette grille va aussi permettre de placer les objets ai sein du texte pour grandir les alignements.

requête

id : 20210405160832
dernière édition :
type : processus
mots-clés : code

Les requêtes (ou appels) sont des demandes soumises par les clients aux serveurs 🔗. Elles sont soumises à un protocole et comportent une entête, un corps. Elles attendent une réponse, soit une erreur, soit un set de données de retour.

Elles peuvent éventuellement comporter un jeton d’identification/d’authentification permettant d’utiliser une API 🔗. Elle pourra ainsi exercer son contrôle en refusant ou non de délivrer les informations.

réseau

id : 20210414220755
dernière édition :
type : architecture

On explicite souvent le réseau grâce à des métaphores naturelles ; on parle de « toile », de « rhizome », de « filet » fidèles à la représentation visuelle que l’on se fait d’un « ensemble de lignes qui s'entrecroisent plus ou moins régulièrement »[^2], mais aussi à sa nature pharmakon, à la fois remède et poison. En effet, le réseau peut être tantôt libérateur, tantôt prison et donner l’illusion du premier pour cacher la réalité du second.

Rien que dans le domaine de l’informatique, le réseau peut se matérialiser concrètement (réseau gravé sur les circuits imprimés) et de manière abstraite, comme un ensemble de relations entre des objets dans un espace 🔗. Il circule un flux en son sein.

C’est la rétistique (néologisme créé par Gabriel Dupuy), la technologie réticulaire, appliquée à des espaces réticulés.

« Le réseau est de nature duale : c’est à la fois une technique concrète, structurante d’un milieu ou d’un objet, et une technologie, c’est-à-dire un regard analytique sur le monde »[^1]

[^1]: Florian Harmand, Arthur Perret, Former à la notion de réseau par la conception et l’interprétation : l’atelier Reticulum, 2021 [^2]: CNRTL, Réseau

responsive

id : 20200715204714
dernière édition :
type : undefined
mots-clés : web

Le responsive design porte sur la conception et la réalisation de supports de contenu adaptés à une diversité d’écran.

Mobile first

Avec l’augmentation « mobilenautes » (utilisateurs du web sur téléphone portable), le responsive design est devenu une nécessite pour de nombreuses plateformes. Cela s’est concrétisé notamment par l’action de l’entreprises Google (91,29% de part de marché sur la recherche web en 2020) qui a décidé de priorisé les site « mobile first » sur son moteur de recherche et de lancer AMP, un framework pour réaliser rapidement une version de son site web dédiée au mobile.

Intégration web

Pour intégrer des pages web responsive, plusieurs outils CSS sont désormais la norme sur les navigateurs les plus utilisés.

🔗 css cascading style sheets

On compte tout d’abord sur des grilles verticales, soit un découpage horizontal du contenu en blocs pouvant s’empiler au fur et à mesure que la zone d’affichage se réduit. Pour gérer cela il existe les media queries, mais aussi deux familles de propriété, flex et grid, qui permettent d’aligner facilement ces blocs.

L’unité du rem est une unité de mesure des pages très puissante, basé sur la racine de la page. Les propriétés font-size, margin et autres peuvent ainsi être adaptées de manière très couple :

html { font-size: 62.5%; }

body {
    /* tous les textes auront une
    hauteur de base de 14px */
    font-size: 1.4rem;
}

@media (max-width: 600px) {
    /* si affichage plus petit que 600px
    la taille du texte diminue drastiquement */
    html { font-size: 58.5%; }
}

rétro-ingénierie logicielle

id : 20211020103649
dernière édition :
type : processus

La rétro-ingenierie (reverse engineering) conciste à étudier un système afin de déterminer son fonctionnement et la manière dont il a été conçu. Dans le cas de l’étude de logiciel, cela conciste à identifier les artefacts 🔗 du système et leur organisation[^1] (p.2) pour renverser l’abstraction 🔗. Ce renversement permet de passer d’une abstraction tiers (ordinogramme 🔗, documentation du système 🔗…) à une abstraction de la source.

[^1]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

rhizome

id : 20210915102826
dernière édition :
type : architecture

Le rhizome est un graphe 🔗 mouvant, dont l’intérêt réside dans la multiplicité des connexions.

« le rhizome connecte un point quelconque avec un autre point quelconque, et chacun de ses traits ne renvoie pas nécessairement à des traits de même nature, il met en jeu des régimes de signes très différents et même des états de non-signes. Le rhizome ne se laisse ramener ni à l’Un ni au multiple. […] Il n’est pas fait d’unités, mais de dimensions, ou plutôt de directions mouvantes. Il n’a pas de commencement ni de fin, mais toujours un milieu, par lequel il pousse et déborde »[^1] (p.11)

Par cette multiplicité et la richesses de ses connexions, c’est le réseau entier qui se requalifie en permanence.

« Une telle multiplicité ne varie pas ses dimensions sans changer de nature en elle-même et se métamorphoser »[^1] (p.11

« Contre les systèmes centrés (même polycentrés), à communication hiérarchique et liaisons préétablies, le rhizome est un système acentré, non hiérarchique et non signifiant, sans Général, sans mémoire organisatrice ou automate central, uniquement défini par une circulation d’états »[^1] (p.11)

[^1]: Gilles Deleuze, Félix Guattari, Mille Plateaux, 1980

runtime ou environnement d’exécution

id : 20201224140951
dernière édition :
type : architecture

Un runtime, ou environnement d'exécution, est un logiciel permettant d’exécuter des programmes dans un langage de programmation donné. Il est lui-même basé sur un langage de programmation. Il offre la possibilité d’utiliser des services du système d’exploitation, de gérer les erreurs.

Il peut être vu comme une machine virtuelle transformant les instructions d’un « code objet » en « code natif » (lisible par le processeur) pour le transmettre au processeur, ad hoc. Ainsi, il va interpréter le code source dans le cas d’un langage interprété 🔗.

Exemples

NodeJs est un runtime permettant de créer des programmes pour différents systèmes d’exploitation avec le langage JavaScript.

Ruby on Rails et Django permet de de développer des sites internet respectivement avec les langages Ruby et Python.

script

id : 20210408103043
dernière édition :
type : programmation
mots-clés : code

Ce sont des codes implémentés dans un langage de programmation interprété 🔗 par un logiciel exécutant. Ils permettent de manipuler les fonctionnalités du logiciel avec la capacité systématique des algorithmes 🔗.

logiciel exécutant langage
navigateurs web JavaScript
After Effect (Adobe) CommonJs (JavaScript)
NodeJs CommonJs (JavaScript)
Maya Python

Le logiciel Photoshop (Adobe) proposent de programmer graphiquement 🔗 les scripts.

semantic web stack

id : 20200915084904
dernière édition :
type : architecture
mots-clés : informatique, scienceinformation, websemantique

Le semantic web stack est une représentation des différentes couches du web sémantique, soit une hiérarchie de langages informatiques, et dont chacun dépend du traitement de celui qui le précède.

Ainsi le web sémantique est une environnement complexe, hypertextuel permettant d’échanger des données structurées.

🔗 la donnée

![semantic web stack](./images fiches/semantic web stack.png)

Dans Lu, Vu, Su, Jean-Michel Salaün distingue quatre temps dans ce processus :

  1. identification des ressources ;
  2. formalisation des données avec les langages ;
  3. indexation et mise en place des moteurs pour interroger (query) les données ;
  4. assemblage des ressources durant un processus authentifiant.

Identification des ressources

Le système débute par la localisation des ressources via leur identifiant URI (dérivé des IRI).

🔗 URI, uniform resource locator

Formalisation des données

Le RDF (Resource Description Framework) est un langage de balisage permettant de structurer des documents et, pour le web sémantique, d’attribuer des métadonnées aux différents éléments.

Ces métadonnées sont issues d’ontologies et viennent apporter du sens (une fonction) au différents éléments du document. Ce triplet vient former un graphe.

🔗 triplet RDF

Il est aussi possible d’utiliser la norme JSON-LD (JSON Linking Data).

Ils ont eux-même identifiés par des URI et pouvant donc être intégrés à d’autres documents. Il devient alors possible de dresser une toile entre les documents, de rassembler leurs ressources.

🔗 ontologie

flowchart TD

ontologie1((ontologie))
ontologie2((ontologie))

subgraph document1
ressource1[ressource]
ressource2[ressource]
ressource3[ressource]
end

subgraph document2
ressource4[ressource]
ressource5[ressource]
ressource6[ressource]
ressource7[ressource]
end

ontologie1 -->|est le titre| ressource1
ontologie1 -->|est l'auteur| ressource2
ontologie1 -->|est la langue| ressource3

ontologie1 -->|est le titre| ressource4
ontologie2 -->|est l'auteur| ressource5
ontologie2 -->|sont les mots-clés| ressource6
ontologie2 -->|est la langue| ressource7

Indexation et requêtes

🔗 requête

Le SPARQL (Protocol and RDF Query Language) est un dérivé du SQL permettant de naviguer de document RDF en document RDF pour y retrouver des ressources.

🔗 base de données

On délègue aux machines la recherche d'information en leur fournissant une demande formalisée « remplaçant ainsi de fastidieuses recherches humaines d’informations, de plus en plus imprécises, du fait de l’hétérogénéité des formats et du cloisonnement des applications »[^1]. C'est l'utilité heuristique (capacité de découverte) du web sémantique.

Assemblage et authentification

Toute le processus est protégé par une barrière crypto (un chiffrement des échanges) pour aboutir à un trust, une version fiables des données. On souhaite tout au long du processus traiter des données intègres pour enfin les déployer sur une interface utilisateur. Le terme « application » renvoie à un fenêtre de gestion de ces données pour une exploitation du web sémantique.

🔗 interface

[^1]: E.S Michael et V.R Marcello, Pratiques de l'édition numérique, 2014

sérialisation des données

id : 20201003174114
dernière édition :
type : architecture
mots-clés : code, informatique

🔗 la donnée

Il s’agit de modifier la structure d’un jeu de données partant de sa structure d’origine pour en obtenir une nouvelle qui permettra de manipuler ces données.

L’organisation d’un set de données dépend d’un projet système. Un choix de structure pour ses données induit et limite un traitement futur qu’il est donc nécessaire de penser en amont. On voit dans l’exemple ci-dessous deux structures différentes de la même information.

{
	"adresse" : "115 Cours d'Alsace-et-Lorraine 33000 Bordeaux"
}

{
	"ville" : "Bordeaux",
	"code_postal" : 33000,
	"voie" : "Cours d'Alsace-et-Lorraine",
	"num" : 115
}

Exemples

Nous allons inscrire ci-dessous le même jeu de donnée sous différents langages :

CSV

Le CSV est la structure la plus compacte et la plus efficace bien qu’elle ne soit nativement ni adaptée à la lecture humaine (sauf en alignant les virgules), ni à lecture machine (sauf traitement préalable). C’est aussi le format le plus simple à obtenir via le tableur de notre choix.

Ils représentent des vues (« photographie de la donnée »), et ne peuvent contenir le contenu que d’une seule table.

id,name,mail,pass
1,guillaume,guil@myllaume.fr,7GrzT86Be
2,mael,ml@myllaume.fr,5R9Cir2zP

JSON

Le JSON est plus verbeux (les métadonnées sont répétées pour chaque objet, suivies de leur valeur), mais aussi adapté à l’interprétation par la plupart des langages de programmation, notamment le PHP et la JavaScript. Il peut être directement inscrit dans ce dernier.

JSON peut contenir plusieurs objets 🔗.

[
    {
        "id": 1,
        "name": "guillaume",
        "mail": "guil@myllaume.fr",
        "pass": "7GrzT86Be"
    },
    {
        "id": 2,
        "name": "mael",
        "mail": "ml@myllaume.fr",
        "pass": "5R9Cir2zP"
    }
]

XML

Le XML est sans doute le plus lourd à lire et écrire, mais c’est aussi celui qui nous permet d’enrichir le plus efficacement les données, notamment en appliquant certaines normes.

Il aurait aussi été possible de faire l’id une balise <id> plutôt qu’un attribut. On voit bien que le XML permet d’avoir des données bien plus riches puisque pour toutes les balises il serait possible d’apporter des précision sur leur valeur avec des attributs.

<?xml version="1.0" encoding="UTF-8"?>
<users id="1">
  <user>
    <name>guillaume</name>
    <mail>guil@myllaume.fr</mail>
    <pass>7GrzT86Be</pass>
  </user>
  <user id="2">
    <name>mael</name>
    <mail>ml@myllaume.fr</mail>
    <pass>5R9Cir2zP</pass>
  </user>
</users>

YAML

Le YAML est la structure de données la plus lisible pour les humains ; il faudra convertir le format pour une interprétation machine. Du JSON vers le YAML (et inversement) il ne s’agit pas d’une sérialisation, mais d’une transpilation : le YAML est un sur-ensemble (superset) du JSON.

🔗 transpiler ou compiler du code

-
    id: 1
    name: guillaume
    mail: guil@myllaume.fr
    pass: 7GrzT86Be
-
    id: 2
    name: mael
    mail: ml@myllaume.fr
    pass: 5R9Cir2zP

signe formel

id : 20201012091721
dernière édition :
type : inscription
mots-clés : Bruno Bachimont, Samuel Goyet, linguistique

Le raisonnement computationnel ne s’exprime pas exclusivement par les signes mathématique

Signe en mathématiques

Les entités naturels permettent de compter des objets, de comparer des quantités, sans avoir besoin de manipuler ces objets.

« le chiffre renforce l’abstraction permise par l’écriture »[^2] (p.168) car il est commensurable. Par exemple, écrire « 15 » sur une feuille de papier permet de signifier à la fois « 15 jours, « 15 pommes » ou tout autre quantité d’éléments définis a posteriori.

« Le principe de commensurabilité, c’est prendre ce niveau du signifiant pour en abstraire la seule quantité (quinze), quantité que l’on va pouvoir attribuer à d’autres signifiés, pour autant que les deux signifiés mis en relation d’équivalence par un seul et même signifiant soient tout deux dénombrables »[^2] (p.168)

Le chiffre est aussi convertible ; donner une valeur (litre, kilo…) à ces unités permet de varier les échelles. Addition, multiplication, soustraction ou division, ce sont autant de formules permettent de manipuler ces signes.

« le mathématicien formaliste mobilise une symbolisme qu’il manipule à travers une combinatoire réglée par des lois formelles, c’est-à-dire appliquées uniquement en vertu de la forme indépendamment du contenu signifié »[^1]

Signe en philosophie

En philosophie (comme mère de toutes les sciences, toutes sujettes aux problématiques de la prose qui vont être évoquées), les signes sont des mots. L’auteur mobilise des concepts à travers des mots profitant de leur polysémie pour pouvoir se les approprier (les adapter à son propos), ainsi que leur sens. Ainsi, un même mot chez différentes philosophes désigne un concept différent (en degré, voire en nature).

Cette souplesse nécessite de la prudence. Il faut se garder

  • du « verbalisme, c’est-à-dire la tendance formelle à faire confiance aux mots et à leur combinaison sans vérifier les implications au niveau du contenu »
  • du « mysticisme, c’est-à-dire la tendance intuitionniste à se fonder sur un contenu qu’on ne peut jamais voir ni communiquer ou faire partager »[^1].

« le raisonnement discursif fondé sur les signes linguistiques bénéficie d’une combinatoire dont l’aveuglement au contenu conduit à la cécité du raisonnement »[^1]

[^1]: Bruno Bachimont, Signes formels et computation numérique : entre intuition et formalisme, 2004 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

site statique

id : 20210218203301
dernière édition :
type : processus

Un site web est composé de trois type de fichier, correspondant à trois langages (formant le code source) et usages bien distincts en rapport avec les pages web :

  • HTML (structure des pages)
  • CSS (apparence, placement et animation des éléments)
  • JavaScript 🔗

Ces fichiers vont du serveur au client 🔗. Le serveur peut être utilisé comme un compilateur 🔗 de ces trois fichiers. C’est un traitement dynamique. Le code source de la page web va être adapté d’après des paramètres de session. Par exemple, pour afficher ou non des commandes à un utilisateur selon ses droits d’accès (suite à une authentification). Ou encore quand d’une base de données on extrait le contenu d’une page web générée à la volée, même via une requête asynchrone 🔗. C’est un dispositif très complet nécessitant une maintenance régulière.

Le serveur peut aussi simplement envoyer le code source tel qu’il a été écrit par les développeurs, sans traitement. C’est le cas pour un site statique dont les fichiers ne font l’objet d’un traitement qu’avant leur mise en ligne. Une fois connectés au Web, ces site ne consomment que les ressources nécessaire à leur envoie. Ces pages restent interactives dans leur utilisation, mais le code, le contenu qu’elles contiennent est fixe.

Mode de templating

Les modes dynamiques et statiques permettent tout deux de faire du templating 🔗, mais avec un processsus de traitement tout à fait différent.

Le mode dynamique implique d’inclure les parties de la page à la volée. Le serveur va réaliser le traitement avant d’envoyer les fichiers au client. C’est un calcul machine systématique (gourmand en ressources) pour chaque utilisateur, ne serait-ce que pour un rechargement de page.

Le mode statique implique de n’effectuer aucun traitement. Le templating 🔗 a été réalisé par les développeurs avant la mise en ligne des pages. Des générateurs de site statiques comme Hugo (particulièrement rapide) ou 11ty (particulièrement formidable) permettent de générer l’intégralité des fichiers à envoyer au client, tel quel.

Le cache est un mode entre-deux. Il permet d’éviter les générations intempestives de pages en sauvegardant temporairement tout ou partie de leur dernière forme pour ne pas avoir besoin de la re-calculer avant envoie au client.

Pérennité

Un site statique n’émet que des requêtes 🔗 standards (de machine à machine), ne supporte pas l’authentification ou d’autres techniques qui nécessiteraient de valider des opérations potentiellement risquées.

Il ne peut y avoir d’erreur de programmation avant l’envoie des fichiers au client, ce qui limite les indisponibilités.

site web lowtech

id : 20200709214912
dernière édition :
type : processus
mots-clés : web

« L’idée générale est de choisir des solutions techniques minimalistes, légères et simples. Les enjeux sont à la fois économiques, écologiques, politiques »[^2]

  • peut être compris pas tous

La lowtech web consiste à développer des sites web légers, tant en terme de design (brutalist web design 🔗) que d’architecture. Ils sont formés de pages statiques (par opposition à dynamique, ces pages ce sont pas générées avant d’être envoyées à l’utilisateur).

« Un site web n’est pas un magazine, même s’il peut contenir des articles de type magazine. Un site web n’est pas une application, même si vous pouvez l’utiliser pour acheter des produits ou interagir avec d’autres personnes. Un site web n’est pas une base de données, même s’il peut être géré par une base de données. Un site web a pour but de donner aux visiteurs du contenu à apprécier et des moyens d’interagir »[^1]

Le site web lowtech est minimaliste et cela a plusieurs avantages comme les présente les sites Motherfuckingwebsite et Bettermotherfuckingwebsite :

  • impact environnemental plus faible
  • lisibilité du contenu

Références :

  • https://collectif.greenit.fr/ecoconception-web/

[^1]: David Bryant Copeland, Guidelines for Brutalist Web Design, 2020 [^2]: Marcello Vitali-Rosati, Ce qui pourrait être autrement: low tech, 2021

skeuomorphisme

id : 20200708113814
dernière édition :
type : modélisation
mots-clés : lectureecriture, scienceinformation

🔗 interface

Le skeuomorphisme (néologisme) est « un style de conception qui donne aux programmes l’apparence d’objets physiques »[^1]. On le retrouve dans les premiers interfaces d’application : les « petites-roues du vélo » mises en place pour qu’une masse d’utilisateurs puisse accéder à ces outils facilement.

On retrouve notamment le skeuomorphisme dans l'ancienne version de l'application iBooks de Apple. L'interface prend la forme d'une étagère et chaque action (ouvrir le livre, tourner les pages…) imite l’interaction physique.

« La bibliothèque virtuelle en bois nous fait croire que quelque chose subsiste de la relation intime à la lecture, comme s’il fallait réenchanter l’absence d’épaisseur physique par des formes historiquement balisées »[^2]

On peut regretter l’icône de la disquette, matériel désuet mais qui symbolise toujours la sauvegarde et sert encore de bouton pour cette fonctionnalités dans certains logiciels.

Lexique

On garde de ce temps d’adaptation tout un « lexique skeuomorphique », attaché à des éléments réels, réutilisé pour parler d’éléments d’interface comme le bureau qui s’affiche au démarrage, les dossiers, fichiers. Ce lexique est encore utilisé pour pallier une utilisation abstraite de l’informatique.

Il ne faut pas absolument changer de ce vocabulaire : ce que désignent les mots bureau et dossiers doit bien porter un nom.

« nous opérons toujours avec des références datant du début du 20ème siècle »[^1]

[^1]: Arthur Perret, Matière à pensées : outils d’édition et médiation de la créativité, 2018 [^2]: Anthony Masure, Le design des programmes, 2014

software/hardware

id : 20210415160329
dernière édition :
type : undefined

Le hardware désigne le matériel informatique. On lui oppose le software, le logiciel. Le premier peut être manipulé par les humains par le biais du second.

On trouve du matériel dans les logiciels avec les émulateurs 🔗 et du logiciel dans les matériels avec les firmware (logiciels embarqués, intégrés dans du matériel informatique).

Il y a entre ces deux notions une tension

  • économique, dans la mesure où le matériel a dans un premier temps été très cher, bien plus que le logiciel. Cette tendance est désormais radicalement inversée et évolue même vers une gratuité du logiciel financé par le commerce des données en ligne. 🔗 travail gratuit, économie du web de plateforme
  • de compatibilité des logiciels d’une machine à l’autre : l’encodage 🔗 des programmes a longtemps cantonné l’utilisation de certains logiciels à des machines spécifiques, si bien que la distinction software/hardware est apparue plus tardivement, dans les années 50. Désormais, cette tension a quasiment disparue avec la standardisation et l’industrialisation des machines. Le marché du logiciel change alors radicalement : on ne fait plus de sur-mesure, mais des logiciels vendus en masse.

Compatibilité

La machine est désormais « neutre […] capable d’imiter n’importe quelle autre machine »[^1] (p.97). Les modèles des applications 🔗 est le paroxysme de ce paradigme.

La rupture matériel-logiciel n’est pas absolue. Aucun logiciel ne peut fonctionner sans matériel, sans ses défauts techniques, inhérents à sa structure ou bien causés par sa fabrication. En revanche, un logiciel peut être développé sur une machine et déplacé sur une autre, modifiant ainsi les conditions de son exécution.

🔗 matérialité d’un programme

Créer un programme capable de s’exécuter sur de nombreuses machines nécessite de monter en abstraction (d’augmenter le niveau de programmation 🔗), de se baser sur des logiciels déjà standardisés et installés sur les machines plutôt que de développer des programmes dédiés au matériel.

« la mise au point du concept d’ordinateur à programme en mémoire interne va remettre l’accent sur l’abstraction logique des programmes »[^1] (p.114)

Le logiciel n’existe pas

Un logiciel par rapport à un autre n’est qu’une variation dans l’enchaînement des processus limités par le matériel. Ce sont les mêmes composants de silicone, les mêmes circuits qui sont empruntés par un logiciel ou par un autre. Le courant va et revient faisant du logiciel une « chaîne infinie d’autosimilarités »[^2] (p.33). Ainsi chercher quelle est la source de fonctionnement d’un programme est un ensourcellement.

🔗 fétichisation des programmes

[^1]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^2]: Friedrich Kittler, Mode protégé, 2015

spécification

id : 20210813142419
dernière édition :
type : processus
mots-clés : projet

La spécification est la transformation d’un besoin en une solution technique comprenant un ensemble d’exigence quant à sa qualité. La spécification devient l’outil d’évaluation de la réponse technique au besoin, sa norme technique. Un produit qui ne satisfait pas les spécifications qui lui sont prescrites est « hors spécification ».

On peut attribuer à certaines spécifications particulièrement importantes un test 🔗 automatique validant leur bon fonctionnement. La description de ce test est alors partie intégrante de la spécification.

stratégies de debug

id : 20211007144052
dernière édition :
type : programmation

Un développeur peut adopter différentes stragégies pour corriger un dysfonctionnement (fix a bug, to debug).

Il peut choisir de lire le code jusqu’à trouver le dysfonctionnement. Il est possible en commentant 🔗 le code de désactiver certaines parties du processus et ainsi de voir lequelles sont en échec. Les ordinogrammes 🔗 permettent de voir ces parties du processus et d’anticiper (en fonction de leurs relations) lesquelles peuvent être mises en échec.

En JavaScript, des méthodes de la classe consol permettent d’intéragir avec le programme en notifiant le développeur à un point qu’il a choisit quel est l’état de certaines variables. Il peut ainsi tester chaque instruction pour préciser lequelles sont en échec.

Ainsi, pour corriger un dysfonctionnement, il n’est pas nécessaire de comprendre comment fonctionne le programme[^1] (p.174).

[^1]: Bill Curtis, Experimental evaluation of software documentation formats, 1989

stratégies de navigation

id : 20210702114815
dernière édition :
type : documentation

Dans une documentation logicielle 🔗 volumineuse, l’utilisateur ne va pas se contenter de consulter le document du début jusqu’à l’information qu’il cherche. Nous allons lui proposer des outils pour qu’il puisse bondir d’une information à une autre (lecture non-linéaire) grâce à des liens hypertextes 🔗 répartis dans des index et dans le texte.

Modalités

S. Elliott Sim différencie deux modalités de navigation différentes (voir ci-dessous)[^1] (p.1). Les utilisateurs peuvent passer avec fluidité entre ces deux modalités : « un utilisateur peut effectuer une recherche pour trouver un point de départ pour sa navigation. Ou bien au cours de la navigation, un utilisateur peut trouver un mot-clé approprié à utiliser pour une recherche »[^1] (p.4).

  • recherche (query) : « activité planifiée avec un objectif spécifique » impliquant de formuler des requêtes (généralement via un moteur de recherche) ;
  • navigation (browse) : c’est une activité heuristique, d’exploration.

Ces modalités ne peuvent fonctionner que si les éléments du système d’information sont correctement identifiés.

Les stratégies de navigation engagées dépendent du niveaux des utilisateurs 🔗. Un développeur est habitué à la documentation du logiciel. Il a avec le réutilisateur des connaissances suffisantes des envrionnements de développement hypertextuels 🔗 pour adopter une navigation reticulaire, des « stratégies de compréhension descendantes et ascendantes »[^1] (p.4) et pour utiliser des termes de recherche précis. Un utilisateur aura une navigation plus linéaire, des termes de recherches moins pertinents.

Division de l’information

Le document est hierarchisé sur trois niveaux imbriqués :

  1. Les chapitres (catégorie d’informations)
  2. Les parties (ensemble cohérent d’informations)
  3. Les points (unité d’information, éventuellement réparties en section et sous-sections)

Chaque division du texte est une ancre, une entrée dans la table des matières. Ainsi, le lecteur est obligé de naviguer selon la division prévue par les auteurs du document. Il sera redirigé au début d’un tutoriel et non à une étape intermédiaire.

La navigation linéaire consiste à lire le document point après point. Ce sont eux qui contiennent les informations. La hierarchie n’est là que pour guider le lecteur à déterminer les points qui pourraient l’intéresser. Le lecteur peut débuter sa lecture depuis n’importe quel point et revenir à l’introduction de sa partie, de son chapitre, décider de se rediriger.

On peut attribuer un type à ces divisions du texte permettant de déterminer leur forme et leur contenu. Par exemple, une partie peut être du type « Foire aux questions ». Ses points corresponderont donc à des paires question-réponse.

Au sein du corps de texte, on distingue des blocs. Un bloc peut correpondre à tout ou partie du point auquel il est intégré. On peut par exemple disposé un bloc pour chaque étape d’un tutoriel au sein d’un même point. Pour être un point, le tutoriel doit transmettre une information complète et pour cela toutes les étapes doivent être intégrées au même point, même si visuellement ils sont distincts. Un bloc peut être une ancre, une entrée dans le sommaire du point.

Référence

La base du travail hypertextuel de redirection de l’utilisateur est la division de l’information et son indexation. Pour chaque information on détermine un identifiant. Dans un document paginé, l’identifiant est le numéro de page. Dans une page web, l’identifiant est une adresse avec un éventuel hash tel que #chapitre-1.

Il est important de différencier visuellement les références à des documents externes, des références internes d’un même chapitre et des référence internes à un autre chapitre. Sans cela on risque de mener le lecteur en dehors du périmètre dans lequel il souhaite évoluer.

Index

On intègre plusieurs type d’index au sein des documents. Ce sont des listes ordonnées de références (description liée à un identifiant) internes ou externes au document.

  • sommaire (liste résumée des partie d’un document)
  • tables (index exhaustifs)
    • des matières (liste complète des parties et des sous-parties d’un document)
    • des figures
    • des tableaux…
  • notes de bas de page
  • glossaire
  • bibliographie

Des index thématiques permettent à l’utilisateur de parcourir une liste de référence d’un autre point de vue que celui de la hierarchie du document, de l’ordre alphabétique. C’est par exemple des index « Pour en savoir plus », « Les principales fonctionnalités ».

Les descriptions attachées aux identifiants sont très importantes. Elles doivent induire au lecteur ce qui va être abordé. Cette attention se traduit par des titres explicites (suggérant le contenu de toutes leurs sous-sections), une biliographie annotée (courte description de chaque référence), des tableaux et figures titrées, des ancres de notes de bas de page efficaces…

[^1]: Susan Elliott Sim, Browsing and searching software architectures, 1999

strates des langages de programmation

id : 20200718172257
dernière édition :
type : programmation
mots-clés : Cléo Collomb, Samuel Goyet

🔗 architexte

L’informatique fonctionne grâce à des circuits logiques électriques, des portes (transistors) fermées ou ouvertes, soit respectivement 0 et 1 (binaire). Ce sont les notions matérielles des programmes 🔗. Lorsque un humain développe un logiciel, il ne saisit pas ces séquences du domaine du langage machine (par opposition aux humains). Aussi, il y a plusieurs paramètres de l’ordinateur à gérer pendant l’exécution d’un programme comme la mémoire (les registres), l’adressage et les instructions machines (opérations élémentaires). En tant que développeur en couche haute, on délègue cette gestion à des programmes que l’on n’a pas besoin de commander dans notre code source 🔗.

Métaphore

On image en développement logiciel la superposition de states métaphoriques. Un code source est analysé par un logiciel qui va retranscrire le programme à un autre logiciel, et ainsi de suite… c’est la descente des couches… jusqu’à arriver à la dernière couche où les instructions deviennent des impulsions électriques au processeur ou destinés à d’autres composants matériels.

Haut niveau et bas niveau sont théoriques ; « un programme écrit en assembleur n’est pas exécuté dans une partie de la machine plus ‹ proche › du processeur qu’un programme écrit en Java. Cette métaphore sert surtout à penser les rapports entre l’humain et l’objet technique qu’il manie »[^2] (p.480).

Archéologique

C’est aussi une idée archéologique, selon laquelle les couches se superposent au fur et à mesure de l’histoire de la programmation[^4] (p.50) :

  1. av. 1945 : câblage (dans un ère matérielle de l’informatique 🔗)
  2. 1945-55 : binaire
  3. 1955-65 : langages d’assembleur
  4. 1965-80 : langages de programmation de haut niveau

Abstraction

On différencie les langages de programmation de haut niveau et de bas niveau selon leur abstraction 🔗, leur détachement des conditions matérielles et fonctionnelles (binaire et portes logiques) de la machine pour simplifier la prescription de processus. D’autres logiciels sont chargés de traduire ces instructions vers les couches plus bases. Au plus haut on trouverait l’interface graphique.

« Aller plus ‹ bas › donnerait accès à plus de pouvoir ou à une meilleure compréhension des médiations en cours »[^2] (p.477)

« L’espace est axiologisé [on donne des valeurs à ses parties] : le « bas » est ce qui serait le plus décisif, là où le pouvoir se décide, là où les décisions de l’utilisateur, du «haut», sont contraintes, ordonnées, préécrites »[^2] (p.480)

Haut niveau

Les langages de haut niveau sont souvent appelés « langages de programmation », non pas qu’ils ont le monopole de la programmation, mais ils permettent d’appréhender simplement le fonctionnement complexe d’un système informatique pour un humain avec des chaînes alphanumériques : ils peuvent intégrer des mots usuels des langues naturelles, les chiffres, la ponctuation et des symboles mathématiques.

C’est une « textualisation de l’activité computationnelle »[^1], une abstraction 🔗 du fonctionnement calculatoire de la machine. Cette simplification de l’organisation des processus faciliter la lecture/écriture des programmes pour les humains, mais empêche aussi les usagers d’exploiter totalement les possibles de la machine. Elle « déborde »[^1] toujours de ce qui peut potentiellement écrit par un humain.

« utiliser des langages alphanumériques de haut-niveau, c’est déjà anthropomorphiser la machine, et réduire toutes ses actions à la commande supposée les provoquer »[^3] 🔗

Il est nécessaire de les compiler en langage machine ou de les interpréter avec un logiciel pour les exécuter. Afin de gagner du temps en programmation, on accepte d’en perdre en exécution.

🔗 langages compilés ou interprétés

Exemples : C, C++, PHP, JavaScript

Bas niveau

Les langages d’assemblage permettent de manipuler explicitement les registres et d’adresser des instructions au processeur (instructions machines). Ce sont des langages très techniques, très concrets.

Finalement, les langages les plus concrets (qui agissent sur le système) sont ceux qui paraissent les plus abstraits (dans l’écriture) tant les instructions sont précises, normées et peu naturelles. En effet, ils suivent des modèles d’écriture très précis.

[^1]: Cléo Collomb, Faire compter les machines, 2017 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^3]: Wendy Hui Kyong Chun, On ‹Sourcery›, or Code as Fetish, 2008 [^4]: Jakob Nielsen, Usability Engineering, 1993

strates du logiciel

id : 20210603115901
dernière édition :
type : documentation

Ci-dessous une proposition de typologie pour les « couches » du logiciel. Il est nécessaire de passer certaines couches pour faire différentes actions liées à la maintenance 🔗 ou comprendre différentes choses.

Couche Documentation liée Opportunité
interface mode d’emploi utilisation
décomposition fonctionnelle cahier des charges suggestion de fonctionnalité
modularisation convention de développement modélisation 🔗
flot de contrôle 🔗 index de l’API implémentation

strates services

id : 20200724170202
dernière édition :
type : processus
mots-clés : methode

C’est une notion transdisciplinaire. Dans différents domaines de service dont l’organisation du travail est collaborative et complexe on distingue trois espaces :

  • front-office (front-end) : services d’opération auprès de l’usager ;
  • front-office : services de médiation entre front et back ;
  • back-office (back-end) : services d’administration en soutient des opérations.

Généralement, les personnes investies dans des projets de cette envergure se répartissent dans l’une de ces strates et s’y spécialise. Sont dites « full-stack » les personnes investies de manière transversale entre front et back.

🔗 médiation numérique

structure des données

id : 20210509175711
dernière édition :
type : architecture

Dans son article[^1] Pourquoi vos données devraient-elles être dans une application à tout faire (titre traduit), David Karger propose une réflexion autour du stockage et de la retrouvrabilité des données.

On est face à deux écoles. Pour la première il faudrait choisir un système de stockage propre à chaque type de données pour optimiser son indexation et finalement sa retrouvrabilité. Il s’agit de traiter des données structurées opposée à une base de données « tout venant », « jetez tout là-dedans et retrouvez le ». Mais gagne-t-on vraiment du temps avec cette technique ?

David Karger oppose plusieurs arguments en faveur d’une école du « tout venant ». Le coût de mise en place et de l’interface de mise en place impose un temps d’entrée potentiellement important. De plus les données stockées dans ces systèmes ne sont pas nécessairement faites pour être retrouvées. Aussi, si vous « adoptez une application particulière, vous adoptez son schéma »[^1] (qu’un champ divers n’élargit pas) et ne pouvez les consulter les données « que de la manière dont l’application veut vous les montrer »[^1]. On devient ainsi dépendant de choix prescrits par des développeurs ou bien pressé par l’objectif (dans une certaine mesure) d’en devenir un. Il n’est en effet pas possible de sortir du schéma (natif ou redéfini) de ces applications étant donné qu’elles ne sont pas compatibles entres elles, ne permettent pas de mettre en relation des données externes. « pour effectuer une tâche, il faut souvent ouvrir plusieurs applications différentes, chercher dans l’une les informations que j’ai déjà trouvées dans une autre, ou même les retaper »[^1].

Dans les deux cas, nous perdons en réutilisablité de l’information. Dans le premier cas on renonce à l’interopérabilité entre les systèmes de pensée, dans l’autre au traitement massif des informations. L’outil parfait est entre ces deux fausses harmonies (« Faustian bargains »)[^1], entre structure et flexibilité. On peut utiliser des ontologies généralistes comme le Dublin Core, « un modèle de données structuré universel, contenant des objets de types arbitraires avec des propriétés arbitraires et connectés à d'autres objets par des relations arbitraires »[^1].

L’exploitation de ces données se fait par le biais de vues 🔗 qui vont donner à voir (comme avec le logiciel Notion) différents usages d’une même structuration en simplifiant son affichage (retirer les éléments inutiles).

[^1]: David Karger, Why All Your Data Should Live in One Application, 2010

structure logicielle

id : 20210221144451
dernière édition :
type : architecture

La structure logicielle est le périmètre composé de plusieurs échelles et plusieurs milieux. C’est une base documentaire fondamentallement hypertextuelle 🔗. Les fichiers qu’elle regroupe partagent une grande variété de liaisons par diverses protocoles permettant de faire communiquer ses milieux.

Échelles

Du macro au micro :

  1. arborescence des répertoires (de un à plusieurs milliers de répertoires contenant un ou plusieurs miliers de fichiers)
  2. fichier
  3. structures de contrôle 🔗 (de une à plusieurs centaines de lignes)
  4. variables et constantes 🔗 (une ligne)

L’arborescence des fichiers n’est pas limitée aux éléments d’un répertoire racine. Elle peut être étendue à des services de distribution de fichier (CDN), comme c’est souvent le cas pour les bibliothèques 🔗.

Peut-on théoriquement distinguer ?

  • programme
  • module 🔗
  • structure de contrôle
  • flot de contrôle 🔗

Milieux

Du code source 🔗 est intégré dans ces différents milieux, liés à différentes échelles du logiciel (voire traitant de toutes ces échelles en même temps).

  • code dédié, ad hoc : programmes implémentés par l’équipe de développement pour le logiciel en question.
  • documentation 🔗 : traite de toute la complexité du logiciel, de toutes ses échelles. Bien qu’elle soit propre à chaque logiciel, elle peut avoir pour vocation de déborder de sa structure pour aller traiter de l’environnement de développement (pour maintenance).
  • framework 🔗 : il va prescrire une arborescence et ajouter des structures de contrôle, contrôler l’intégration des bibliothèques.
  • bibliothèques : elle vont être importées dans l’arborescence et ajouter des structures de contrôle.

La structure d’un logiciel telle qu’elle a été décrite s’inscrit dans un milieu plus large qui est celui de l’environnement de développement 🔗. Ainsi, plusieurs logiciels peuvent émerger de cette même chaîne de production 🔗.

structures de contrôle

id : 20200701214359
dernière édition :
type : architecture
mots-clés : code

Les structures de contrôle sont différents composants qui peuvent être inscrits avec une majorité des langages de programmation de haut niveau 🔗. Elles permettent d’encapsuler 🔗 l’information et ainsi de contrôler le flot de contrôle 🔗, la circulation de l’information.

Selon les langages, les mots-clés permettant d’appeler ces structures peuvent légèrement changer. Toutefois, on retrouve globalement le même dictionnaire.

  • conditionnelles : if, else, switch
  • boucles : while, for, foreach
  • les tests : try et catch
  • les fonctions 🔗 : function
  • les classes : class

Une fonction 🔗 est une structure de contrôle dans la mesure où elle permet de répéter une série d’instructions, et ce bien qu’elle soit liée à constante et que, par transparence référentielle 🔗, elle puisse correspondre à une valeur.

syntaxe de code

id : 20200930214400
dernière édition :
type : inscription

La syntaxe est l’étude et la pratique de la combinaison des mots pour former des expressions sur lesquels on projette un sens permettant aux ordinateurs de fonctionner : une sémantique fonctionnelle. On distingue dans les lignes de code différents lexèmes, des unités lexicales.

var y = 5;
var x = {'chat', 'lapin'};

if (y === x) { console.log('impossible'); }

Ci-dessus, 5 et {'cat', 'dog'} sont des littéraux, des valeurs fixes (à ne pas confondre avec une constante 🔗 qui est une variable dont le changement de valeur est simplement bloqué). var est un mot-clé correspondant notamment en JavaScript à une expression permettant à la fois de déclarer, définir et affecter une variable 🔗 à un identifiant, comme ci-dessus y et x. if est un mot-clé renvoyant à une structure de contrôle 🔗 conditionnelle. Le caractère = est un opérateur, signe renvoyant à une opération mathématique, ici d’affectation. S’il est triplé === il devient un opérateur de validation d’un égalité stricte. Les accolades {} permettent en général d’encapsuler 🔗, soit comme ci-dessus des valeurs dans un objet, soit dans une conditionnelle. Le point . permet en JavaScript d’accéder à une propriété d’un objet et ainsi à la méthode log de l’objet console.

Analyse syntaxique

L’analyseur syntaxique (parser) est un programme qui va venir découper le texte en fonction d’un dictionnaire (mots-clés), mais aussi de caractères pour extraire des instructions.

🔗 interpréter un langage

Ce programme, développé à l’aide d’un premier langage de programmation, va ainsi être capable de lire un autre langage et ainsi de le compiler, transpiler.

🔗 transpiler ou compiler du code

Backus-Naur

La forme de Backus-Naur (conçue par John Backus et Peter Naur) est un méta-langage (langage permettant de décrire un langage), une notation permettant de décrire les règles syntaxiques (en) des langages de programmation.

Le code ci-dessous[^1] permet de décrire le fonctionnement d’un langage :

  • les expressions (exp) : on pourra les trouver à la suite des mots-clés var et const, mais aussi des part et d’autre des opérateurs + et - et enfin entre parenthèses ;
  • les déclarations (statement, stm) : on autorise les déclarations ainsi formalisées, telles que les expressions se trouvant à la suite d’un mot-clé var, const (alors suivit de l’opérateur =) ou return et avant le signe ;.
exp ::= var | const | exp "+" exp | exp "-" exp | "(" exp ")"
stm ::= var "=" exp ";" | "return" exp ";"

Variantes syntaxiques

Il y a différentes manières d’écrire une même expression. On s’adapte en général pour la lisibilité.

if(!isset($_POST)) { echo 'Aucune donnée'; }

if(!empty($_POST)
    && !empty($_POST['x']) && trim($_POST['x']) != ''
    && !empty($_POST['y']) && trim($_POST['y']) != '')
{
    // traitement
}

Sucre syntaxique

Inventée par Peter John Landin, l’expression « sucre syntaxique » (syntactic sugar) désigne des variantes syntaxiques d’un langage de programmation qui ne viendraient pas modifier la fonction de l’expression originale, mais viendrait seulement la rendre plus simple à lire et écrire.

Ainsi les deux lignes de code suivantes permettent d’afficher la valeur de la variable $string, mais la seconde est plus rapide à inscrire et à lire.

<?php echo $string ?>
<?= $string ?>

Sel syntaxique

Le sel syntaxique rend plus difficile l’inscription du code dans le but d’éviter les erreurs de saisie. Par exemple, on conseille lors d’un test d’égalité (opérateur == ou ===) d’échanger variable et littéral pour qu’une erreur soit renvoyée si l’on a par inadvertance inscrit une affectation (opérateur =). Ce peut être une consigne prescrite dans la convention de développement 🔗.

if (toto = 10) { … } // pourquoi ça bug ? oups…
if (10 = toto) { … } // erreur, je suis averti
if (10 == toto) { … } // sûr de moi

// sytaxiquement correct, mais ne faites jamais ça !
if ((toto + 2) == 10) { … }

On peut aussi demander aux rédacteurs du code d’être particulièrement explicites dans leur manière d’inscrire une opération.

if (!isset($id)) { return; }
if (isset($id) === FALSE) { return; }

[^1]: Denis Merigoux, La syntaxe pousse sur les arbres, 2017

système combinatoire

id : 20210416144157
dernière édition :
type : architecture

On peut traiter le logiciel comme un système combinatoire, souple et robuste, un « système réglé de permutations entre un nombre fini d’éléments »[^1] (p.84) : Des éléments (unités) peuvent être assemblés, substitués selon certaines règles (« permutations autorisées ») définies par la configuration 🔗 pour former un mashup, un assemblage, un mélange.

« Toute la force de la combinatoire réside dans ce rapport entre une grande économie de moyens – quelques règles et éléments de base – et un grand nombre possible de résultats. Il suffit d’appliquer méthodiquement deux ou trois principes pour arriver à épuiser toutes les combinaisons possibles, ce qui revient à accéder à une totalité finie. »[^1] (p.85)

Les fonctions 🔗 sont des unités pouvant être combinées dans le code source. On dresse une documentation 🔗 pour expliciter la formation de ces combinaisons. La combinatoire est une réponse à la complexité 🔗. Le mot d’ordre pour qu’un tel système fonctionne est la cohérence : « Harmonie, rapport logique, absence de contradiction dans l'enchaînement des parties de ce tout »[^2].

« des blocs de fonctionnalités précodés faits pour pouvoir s’adapter à de multiples contextes d’utilisation […] ces objets informatiques sont pétris d’une pensée combinatoire : divisions d’un programme en unités simples ; abstraction de ces unités en blocs permutables ; solutions techniques pour optimiser les possibilités de permutations »[^1] (p.132)

[^1]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^2]: CNRTL, Cohérence

système d’information

id : 20210117094335
dernière édition :
type : architecture
mots-clés : scienceinformation

« Un système d’information n’est pas autre chose qu’un système complexe de représentations : représentation des flux d’informations, représentations des procédures de tout type, représentations des requêtes d’information, représentations des procédures de consolidation de données »[^1]

Un système d’information a vocation à rassembler une masse d’informations dans toute leur complexité. On va vouloir mettre en place des canaux pour réceptionner l’information, des interfaces pour la représenter 🔗 afin de l’analyser et enfin des programmes de transformation pour pouvoir la formater et la transmettre.

Pour traiter un système d’information on va recourir à l’architecture et au design. Ils permettent respectivement de penser la circulation et l’interaction.

🔗 organisation d’un système d’information

[^1]: Yves Jeanneret, Yves Chevalier, La physionomie des systèmes : diagrammes et représentation, 2009

système multi-agent

id : 20201122110517
dernière édition :
type : processus
mots-clés : intelligenceArtificielle

L’objectif des systèmes multi-agents (SMA) n’est pas de créer des agents intelligents individuellement, mais des comportements massifs pour résoudre des problèmes de plus en plus complexes par la « répartition de l'intelligence »[^1], la distribution de tâches.

Pour que les agents puissent ainsi raisonner en coopération « ils doivent être dotés de capacités de perception et d'action sur l'environnement et doivent posséder une certaine autonomie de comportement, on parle alors d'agents et par conséquent de système multi-agents »[^1].

Paradigmes

On l’oppose à l’Intelligence Artificielle (IA) à l’Intelligence Artificielle Distribuée (IAD). Il y a en effet deux paradigmes : certains scientifiques travaille sur des agents isolés tandis que d’autres les considèrent dans une société. Cette seconde école a donné lieu à la recherche sur les systèmes multi-agents (SMA).

C'est vrai qu'on pense que c'est le paradigme des SMA qui va s'imposer comme prépondérant car il est plutôt difficile de compter qu'un agent existe seulement comme une entité pour lui seul et ne rencontrera pas d'autres agents (soit artificiels ou humains) dans son environnement. […] Par conséquent, on va considérer la dimension sociale d'un agent comme une de ses caractéristiques essentielles.[^1]

Définition

Il n’y a pas de définition unanime[^1] pour un agent :

  • « Un agent est une entité autonome, réelle ou abstraite, qui est capable d'agir sur elle-même et sur son environnement, qui, dans un univers multi-agents, peut communiquer avec d'autres agents, et dont le comportement est la conséquence de ses observations, de ses connaissances et des interactions avec les autres agents » (Ferber, 1995)
  • « Les agents intelligents sont des entités logiciels qui réalisent des opérations à la place d'un utilisateur ou d'un autre programme, avec une sorte d'indépendance ou d'autonomie, et pour faire cela ils utilisent une sorte de connaissance ou de représentation des buts ou des désires de l'utilisateur » (IBM)

On retient les cinq points suivants :

  • situé : capacité d'agir sur son environnement à partir des entrées sensorielles qu'il reçoit de ce même environnement ;
  • autonome : capacité d'agir sans l'intervention d'un tiers (humain ou agent) et contrôle de ses propres actions ainsi que son état interne ;
  • proactif : doit exhiber un comportement proactif et opportuniste, tout en étant capable de prendre l'initiative au bon moment ;
  • capable de répondre à temps : capacité à percevoir son environnement et à élaborer une réponse dans le temps requis ;
  • social : l'agent doit entre capable d'interagir avec des autres agents (logiciels ou humains) afin d'accomplir des tâches ou aider ces agents à accomplir les leurs.

Interaction

L'équilibre entre l'autonomie des agents, dotés d'un comportement plus ou moins intelligent, et la convergence vers un objectif global caractérise l'interaction.[^1]

Les agents peuvent exercer deux types d’action : actions privées (par lui-même) et actions communicatives (entre plusieurs). L’interaction des agents (leur comportement et leur évolution dans l’environnement) dépend de trois paramètres :

  • la compatibilité de leurs objectifs (locaux et/ou globaux) ;
  • la suffisance des ressources dont ils disposent ;
  • la suffisance des compétences dont ils disposent.

Jacques Ferber (Les systèmes multi-agents: vers une intelligence collective, 1995) dresse la classification suivante suggérant de réguler les paramètres d’une certaine manière, en fonction des interactions attendues parmi les sept :

Buts Ressources Compétences Situation
Compatibles Suffisantes Suffisantes Indépendance
Compatibles Suffisantes Insuffisantes Collaboration simple
Compatibles Insuffisantes Suffisantes Encombrement
Compatibles Insuffisantes Insuffisantes Collaboration coordonnée
Incompatibles Suffisantes Suffisantes Compétition individuelle pure
Incompatibles Suffisantes Insuffisantes Compétition collective pure
Incompatibles Insuffisantes Suffisantes Conflits individuels pour des ressources
Incompatibles Insuffisantes Insuffisantes Conflits collectifs pour des ressources

En l'occurrence, la compatibilité des objectifs induira des situations de coopération dès que les ressources ou les compétences sont insuffisantes.[^1]

À la compatibilité des objectifs et à la suffisance des ressources, compétences, il faut ajouter un quatrième paramètre qui est la « condition mentale » de l’argent

Typologie

On distingue deux types d’agents :

  • agents cognitifs ou « intelligents » : ils interagissent en fonction de notions mentales (selon Yoav Shoham), soit notamment : « la connaissance, la croyance, les intentions, les désirs, les choix, les engagements »[^1] entre eux, dans leur environnement ;
  • agents réactifs : il ne sont pas « intelligents » par eux-mêmes, ne se représente ni eux-mêmes, ni leur environnement, ni l’objectif global. Il ne sont que contraintes et obligations. « Leurs capacités répondent uniquement au mode stimulus/action qui peut être considéré comme une forme de communication »[^1], leur interaction est nécessaire, mais pas volontaire.

On trouve dans un SMA peu d’agents cognitifs ou bien de nombreux agents réactifs. Ces derniers sont jugés suffisamment intelligents en grand nombre, en système : « l'intelligence est distribuée entre beaucoup d'agents réactifs et le comportement intelligent devrait émerger de l'interaction entre ces agents réactifs et l'environnement »[^1].

Dans ce modèle, la croyance et la connaissance d'agents sont caractérisées comme ensemble de mondes possibles, avec une relation d'accessibilité qui existe entre eux. L'inconvénient principal du modèle est le problème de l'omniscience logique : les agents croient toutes les conséquences logiques de leur croyance.[^1]

Phases

On peut découper une interaction entre agents en trois phases présentées ci-dessous et qui ne se suivent pas nécessairement. L’interaction est la combinaison de la communications de l’actions.

  1. réception de l’information (ex : changement dans l’environnement) ;
  2. raisonnement à partir des informations acquises ;
  3. émission de messages et/ou exécution d’actions modifiant ainsi l’environnement.

Communication

Une communication est une « forme d'action locale d'un agent vers d'autres agents , l’envoie d’un message». Elle est nécessaire pour la coopération et la coordination d'actions locales pour remplir des objectifs locaux et/ou globaux. Il est possible de limiter la portée de la communication, de choisir des agents interlocuteurs.

On distingue trois types d’actes locutoires et perlocutoires :

  • actes locutoires : formulation d'un énoncé, accomplis si l’énoncé est bien formulé ;
  • actes illocutoires : action effectuée sur l'auditeur lors de la formulation de l'énoncé (ex : recevoir un ordre), accomplis dès que l’on obtient l’effet attendu sur l’auditeur ;
  • actes perlocutoires : conséquences du contexte et non de l’énoncé, accomplis lorsqu'ils sont reconnus par l'auditeur.

Il convient de dresser une ontologie pour contrôler le vocabulaire et formaliser les échanges entre les agents.

🔗 interpréter un langage

« les agents ne communiquent qu'à propos d'un univers assez restreint, cadre dans lequel l'interprétation de la langue est techniquement faisable »[^1]

[^1]: Adina Florea, Daniel Kayser, Stefan Pentiuc, Agents intelligents, 2002

templating de page web

id : 20210906084150
dernière édition :
type : architecture

Le traitement de pages web sert à effectuer des transclusions 🔗. Par exemple, l’entête de page (header) va être codée une fois par le développeur puis inclus dans l’ensemble des pages du site. On évite ainsi de dupliquer le même fragment de code. C’est une optimisation de l’arborescence et cela accélère l’édition des parties récurrentes de la page (modifiées en un endroit pour toutes les pages).

À plus grande échelle, cela permet de faire du templating, de préparer un corps de page complet pour n’y inclure que quelques portions de code intégrées à l’aide de boucles grâce à des outils comme Nunjucks ou Pug.

<head>

    <meta charset="utf-8">
    <title>{{ title }}</title>

</head>

<body>

    <header>
        <h1>{{ title }}</h1>
        
        <nav><ul>
            {% for name, id in pages %}
            <li><a href="./{{ id }}">{{ name }}</a></li>
            {% endfor %}
        </ul></nav>
    </header>

    {{ Content }}

</body>

test logiciel

id : 20210801123729
dernière édition :
type : processus

Des tests réguliers permettent d’attester de la fiabilité d’un programme et d’éviter qu’il ne régresse au fur et à mesure de son développement.

« Le problème clé avec les tests est qu’un test (de n’importe quel type) qui utilise un ensemble particulier d’entrées ne vous dit rien du tout sur le comportement du système ou du composant lorsqu’on lui donne un ensemble différent d’entrées. L’énorme nombre de différentes entrées possibles exclut généralement la possibilité de les tester toutes, d’où la préoccupation inévitable en matière de tests : avez-vous effectué les bons tests ? »[^1] (p.5)

Les tests ne sont pas inutiles, mais ils ne peuvent être utiles (bien utilisés) que si l’on saisit leur limite et qu’on compense notre utilisation. Il faut à la fois tester et raisonner[^1] (p.5), à la fois formaliser des instruction de test et analyser intellectuellement le code. L’intelligence humaine peut apprécier la nuance entre deux tests contradictoires corrects, la situation étant dûe à des changements d’état du système[^1] (p.7).

« Les tests sont désespérément inadéquats… [ils] peuvent être utilisés très efficacement pour montrer la présence de bugs mais jamais pour montrer leur absence »[^2]

Enfin, il faut toujours au maximum simplifier le logiciel pour éviter qu’il ne devienne complexe 🔗, les tests ne permettant pas de compenser cette complexité.

« Si l’on a un choix difficile à faire entre l’investissement dans les tests et l’investissement dans la simplicité, ce dernier peut souvent être le meilleur choix car il facilitera toutes les tentatives futures de compréhension du système »

[^1]: Ben Moseley, Peter Marks, Out of the Tar Pit, 2006 [^2]: Edsger W. Dijkstra, The Tide, Not the Waves, 1997

texte

id : 20210406175708
dernière édition :
type : inscription
mots-clés : scienceinformation

Le texte est « ‹ une configuration de signes de toute nature ›, ces configurations constituant des ‹ systèmes symboliques proposés à l’interprétation › »[^1]

Considérer le texte simplement comme une suite de mots, c’est oublier sa mise en page et les éléments qui l’accompagnent, bien qu’ils partagent l’espace et le sens du texte. Le texte n’est pas non plus nécessairement un livre, « même s’il est un référent culturel »[^2] (p.52).

Le texte est un matériaux que l’on peut manipuler, un « agencement de signes lisible et visible […] parce qu’organisé visuellement […] selon des critères culturels »[^2] (p.53). Ainsi, le texte subit une certaine standardisation visuelle.

Le texte est lu et interprété, il a une « vie » sociale « qui fait que son sens ne peut être déterminé par la seule analyse de son organisation visuelle »[^2] (p.52)

🔗 contrat de lecture

[^1]: Roger T. Pédauque, Le document à la lumière du numérique, 2006, p.104, cité par Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017 [^2]: Samuel Goyet, De briques et de blocs. La fonction éditoriale des interfaces de programmation (API) web : entre science combinatoire et industrie du texte, 2017

texte brut

id : 20200629161610
dernière édition :
type : inscription
mots-clés : lectureecriture, code

Les fichiers de texte brut (plain text, texte clair) sont universels :

  • ils peuvent être ouverts sur tous les systèmes d’exploitation et de nombreux logiciels ;
  • ils correspondent à une infinité d’utilisation d’après les qualités de l’écriture numérique 🔗 ;
  • il est facile de les partager et de les modifier pour tout le monde ;
  • ils sont aussi vieux que l’informatique et il les emportera dans la tombe.

Ils sont omniprésents dans le monde de l’informatique, même là où on ne soupçonne pas leur présence. Ils sont les fichiers de code, de configuration, mais aussi des pages web.

Toutefois, il faut faire attention à leur encodage 🔗 pour garantir leur compatibilité avec les systèmes et éditeurs.

Outils d’écriture

L’autre force du texte brut est la variété d’outils d’édition numérique 🔗 qu’il est possible de lui appliquer, et autant d’interface d’écriture 🔗. Ces fichiers peuvent être facilement analysés par des logiciels pour y trouver des informations, y analyser la syntaxe d’un langage.

Les éditeurs de texte sont les logiciels dédiés à ce type de fichier. Voici quelques exemples, du logiciel préinstallé (permettant ainsi à tous d’ouvrir un fichier de texte brut) à l’éditeur spécialisé.

  • Logiciels préinstallés : Bloc note (Windows), TextEdit (MacOs)
  • Éditeurs avancés, proposant des outils dédiés à l’édition de texte comme les expressions régulières, l’exploration de répertoires, la coloration syntaxique 🔗 : Notepad++ (Windows), BBEdit (MacOs)
  • Environnements d’édition, pour une utilisation systémique de ces fichiers en proposant des outils de complétion adaptés et en connectant certaines expressions qu’ils contiennent pour une interface d’utilisation et d’édition adaptées à des besoins spécifiques (avec des outils programmables 🔗, du versionnement).
    • dédié au code (EDI 🔗) : Visual Studio Code, Atom, Web Storm
    • dédié à la prise de code : Zettlr, Obsidian

La mise en forme de ces fichiers est purement typographique. Ainsi, l’inscription du texte est fluide, on n’a pas besoin d’appuyer sur une touche ou d’exécuter un raccourcis clavier pour le mettre en forme.

théorie du nudge

id : 20200802100201
dernière édition :
type : processus
mots-clés : scienceinformation, design

La théorie du Nudge est une piste de recherche des sciences du comportement, sciences politiques et économiques. En français on traduit nudge par « coup de pouce ». On parle également de « paternalisme libéral ».

Il s’agit d’« inciter des individus ou l'ensemble d’un groupe humain à changer tels comportements ou à faire certains choix sans être sous contrainte ni obligation et qui n’implique aucune sanction »[^1]

On amène les utilisateurs à faire quelque chose en leur faisant croire qu’ils ont le choix.

« Si on leur donne [aux designer de Amazon et Facebook] exactement les metrics, comme par exemple ‹ il faut augmenter de 5 secondes le temps que passe la personne sur tel type de post ›, ils y arrivent avec le design »[^3

🔗 le design

Sur les réseaux sociaux et d’autres plateformes de masse, on assiste à un renversement ; de la rareté de l’information on en vient à la rareté de l’attention (au détriment de l’intention éthique, responsable) :

« Le problème, c’est qu’on est passé très vite d'une situation de rareté à une situation d’abondance de l’information, ce qui a fait de l’attention un objet de rareté »[^2]

Autorité

L’autorité est la capacité de engager l’action par la confiance et non par la contrainte ou l’obligation (Anna Arendt) : faire qu’une personne fasse ce que l’autorité lui dicte sans qu’elle n’est besoin de recourir à la force ou même l’argumentation. Je fais confiance à Google pour me guider, faire mes recherche. Je pourrais faire autre chose et on n’a pas cherché à me convaincre de l’utiliser. Je lui fais confiance.

L’autorité n’est pas quelque chose de dangereux tant qu’elle ne devient par invisible. Hors si cette confiance est produite par un espace structuré (architecture de valeurs) et que l’on perd cette notion d’espace avec le web, alors nous avons là un danger profond.

[^1]: Annabelle Laurent, « Sur son lit de mort, personne ne se dit : "J’aurais aimé passer plus de temps sur Facebook" », 2017 [^2]: Wikipédia, Théorie du Nudge [^3]: Annabelle Laurent, La conscience d'une pollution mentale créée par le numérique émerge, 2017

thésaurus

id : 20200503195405
dernière édition :
type : architecture

Un thésaurus est une arborescence de termes (descripteurs) dont on a caractérisé les relations hierarchiques (lien spécifique ou générique, synonyme, antonyme…). Le thesaurus permettra de décrire que A est parent de B, lui-même parent de C, frère de F. Le thesaurus prolonge l’idée de l’arborescence 🔗.

« Un thesaurus est une liste d’autorité organisée de descripteurs et de non-descripteurs obéissant à des règles terminologiques propres et reliés entre eux par des relations sémantiques (hiérarchiques, associatives, ou d’équivalence). Cette liste sert à traduire en un langage artificiel dépourvu d’ambiguïté des notions exprimées en langage naturel » AFNOR

Une liste structurée de concepts, destinés à représenter de manière univoque le contenu des documents et des questions dans un système documentaire déterminé, et à assister l’utilisateur dans l’indexation des documents et des questions — Van Slype

traces numériques

id : 20200805104653
dernière édition :
type : processus
mots-clés : scienceinformation

🔗 la donnée 🔗 théorie du nudge

De plus en plus les plateformes nous poussent à produire de la donnée pour la capturer. Le sociologue Bruno Latour, appelle les données les « obtenues ». Arthur Perret propose de renommer les data en capta. Effectivement, les internautes ne donnent que rarement leur consentement pour la collecte et l'utilisation de leurs données. « La donnée c’est le nouvel or noir ». L’algorithme devient un outil de contrôle social.

« les géants du web encouragent les usagers à laisser toujours plus de traces de leurs actions (achats, déplacements, consultations, etc.) et de leurs échanges et fournir ainsi une nouvel or noir rendant possible un capitalisme cognitif[^2] face auquel des résistances émergent »[^1] (p.22)

[^1]: Dominique Vinck, Humanités numériques: la culture face aux nouvelles technologies, 2016 [^2]: voir fiche 🔗 digital labor

transaction

id : 20210910105401
dernière édition :
type : processus

Une transaction en informatique est une suite d’opérations suivant certains principes d’intégrité résumés sous l’acronyme « ACID » :

  • atomique : On ne peut se contenter de réaliser qu’une partie de l’opération. Tout échec conduit à interrompre le processus et l’affectation des données.
  • cohérente : Le rendu doit être cohérent selon un modèle 🔗 défini pour la transaction. Il est nécessaire de vérifier si tel est le cas, sinon on doit interrompre le processus.
  • isolée : Les transaction encapsulent 🔗 leurs données qui ne peuvent être lues par d’autres processus, tant qu’il n’est pas achevé.
  • durable : Le résultat de la transaction ne doit pas pouvoir être annulé sans une autre opération dédiée.

transclusion

id : 20210427185546
dernière édition :
type : inscription

La transclusion est l’ancrage (par référence) ou l’intégration de tout ou partie d’un document (ou fichier) dans un autre.

Programmation

C’est une pratique de programmation fondamentale et permettant la logique modulaire 🔗. Au sein de la structure du programme 🔗 (son arborescence) on combine des fichiers texte (leur contenu) grâce à des mots-clés comme includeimportrequire ou link. Par exemple, on va créer un algorithme (fichier root.php) capable de rediriger un utilisateur entre différents affichages et ainsi de faire la transclusion du fichier contenant le code de l’affichage auquel il doit accéder :

switch($user_way) {
    case 'personne':
        require'way_one.php';
        break;

    case 'projet':
        require'way_two.php';
        break;

    case 'publication':
        require'way_three.php';
        break;
}

Cette opération est automatique et transparente ; l’utilisateur aura l’illusion qu’il n’a accédé qu’à un seul document alors que techniquement, il a fallu de nombreuses transclusions (styles, scripts, corps de page, modèles de données…) pour qu’il obtienne sa page. Cette chaîne d’appels hypertextuels est fondamentale au sein du logiciel 🔗.

transparence référentielle

id : 20210109132504
dernière édition :
type : programmation
mots-clés : code

Pour une expression respectant la transparence référentielle, on peut remplacer son appel par sa valeur résultante, sans changer la signification du programme.[^2]

const f = x => x * 2 ;

Avec la fonction pure 🔗 ci-dessus, l’expression f(2) peut être remplacée par 4 sans changer le déroulement du programme.

[^2]: Eric Elliott, Master the JavaScript Interview: What is Functional Programming?, 2017

transpiler ou compiler du code

id : 20200907090751
dernière édition :
type : inscription
mots-clés : web

On différencie les deux processus selon le niveau d’abstraction du code en sortie :

  • transpiler :transformer un langage (de programmation ou non) en un autre, à un niveau d’abstraction égal ;
  • complier : transformer un langage de programmation en un autre, à un niveau d’abstraction inférieur.

🔗 strates des langages de programmation

Transpilation

Ces outils permettent de profiter d’une nouvelle syntaxe, d’un nouvel environnement de développement pour produire un code transpilé selon une norme.

Voici un extrait de code CoffeeScript transpilé en JavaScript :

nb = 2
double -> nb*2
var nb;

nb = 2;

double(function() {
 	return nb * 2;
});

La transpilation ne se fait pas nécessairement d’un langage à l’autre. Elle peut aussi permettre de corriger la syntaxe ou compléter, préfixer les déclarations. Par exemple, l’outil Babel permet de transpiler la syntaxe moderne de JavaScript pour les runtime 🔗 datés. Les transpilations peuvent être enchaînées.

Exemples de transpilations :

  • TypeScript → JavaScript ;
  • YAML → JSON ;
  • PUG → HTML ;
  • SCSS → CSS.

Compilation

La compilation est une opération de traduction et d’allocation de registres. En plus de traduire les structures de contrôles, il est nécessaire de répartir les variables dans la mémoire.

Enjeux

Une compilation/transpilation n’est pas une traduction.

« C'est la différence entre une identité mathématique et une équivalence logique, qui dépend d'un acte de foi »[^2]

Optimisation

« Dans le monde informatique, temps d’exécution, taille de la mémoire utilisée et même nombre d’instructions dans le programme sont autant de paramètres que la traduction cherchera à minimiser. Cette recherche de la performance lors de la traduction engendre des décisions importantes qui influent sur l’ergonomie du langage de programmation […] Ainsi un langage de programmation dans lequel la mémoire est gérée manuellement sera en général plus performant qu’un langage plus commode où cette gestion est déléguée à la traduction. Encore faut-il que celui qui écrive le programme sache gérer efficacement sa mémoire. »[^1]

[^1]: Denis Merigoux, Une nouvelle linguistique, 2017 [^2]: Wendy Hui Kyong Chun, On ‹Sourcery›, or Code as Fetish, 2008

travail cognitif de développement

id : 20210908103929
dernière édition :
type : processus
mots-clés : projet

Les développeurs sont confrontés à différentes problématiques dans leur métier. Il consiste en une « activité de résolution de problème dont la double tâche consiste à définir un problème et trouver sa solution »[^1] (p.4).

On attend d’eux qu’ils accomplissent quatre types de tâches[^2] (p.167) :

  • comprendre
  • coder
  • déboguer
  • modifier

Choix de conception

Marc-Eric Bobillier Chaumon et Éric Brangier notent une série de commentaires sur les difficultés de choix du développeur dans cette variété de solutions.

« il n’existe pas de chemin de solution prédéterminé : à chaque fois il faut réinventer le chemin ; il y a plusieurs solutions admissibles à un problème : le produit final n’est qu’un possible parmi d’autres […] bien que la personne possède des procédures quasi-automatiques, le raisonnement n’est pas procéduralisé. En d’autres termes, le raisonnement ne se déroule pas de manière automatique et irréfléchie mais s’ajuste (opportunément et circonstanciellement) au contexte »[^1] (p.4)

« ces problèmes tendent à être larges et complexes : non réductibles à des problèmes locaux ou à des sous-systèmes indépendants »[^1] (p.4) car bien que l’on puisse modulariser 🔗 le logiciel, l’interface des modules 🔗 ne peut être déconnectée temporairement du reste du programme et reste une source de complexité logicielle 🔗.

« [les problèmes] sont mal définis dans la mesure où des spécifications du problème manquent ; solutionner le problème consiste, en partie, à introduire des contraintes »[^1] (p.4), lesquelles sont consenties et constituent dette technique 🔗, nécessaire pour répondre à l’ensemble des spécifications 🔗, bien qu’elles puissent induire des solutions contradictoires. « l’évaluation de la solution est différée à l’établissement de la solution finale » permettant ainsi de compenser la dette technique 🔗 avant qu’elle ne devienne ingérable.

« la résolution de problème exige la maîtrise et la mise en œuvre de multiples connaissances portant à la fois sur le domaine de l’utilisateur (connaissances fonctionnelles) et sur le domaine informatique (connaissances techniques) »[^1] (p.4) ce qui explique l’importante palette de compétences 🔗 que doit adopter le développeur.

[^1]: Marc-Eric Bobillier Chaumon et Éric Brangier, Évolutions de l’activité et de l’organisation du travail lors du changement d’environnement de programmation chez les informaticiens, 2000 [^2]: Bill Curtis, Experimental evaluation of software documentation formats, 1989

travail gratuit, économie du web de plateforme

id : 20200705100544
dernière édition :
type : processus
mots-clés : web

🔗 logiciel libre et logiciel open source 🔗 communauté de développement

Le web est un système économique particulier basé sur le « travail collaboratif pair à pair dans le monde »[^1]. De partout, des gens produisent gratuitement du contenu, permettant un échange mondial continu dont finalement on ne paie généralement que le coût matériel (et écologique). En effet, l’informatique est un domaine traditionnellement ouvert, gratuit et le web avec : on paie son téléphone, son ordinateur, sa connexion internet, mais peu de nos logiciels et de nos services en ligne.

L’évolution du web en a fait un réseau de plateforme auquel le travail collaboratif (coordination de nos processus de lecture et d’écriture) est soumis.

🔗 production de contenu web

Le web est formé par des plateformes qui pour la plupart sont maintenues par du code bénévole et offrent des services sociaux à l’échelle mondiale, générant des revenus permettant au système de se maintenir (les développeur bénévoles dépendent également de ces même plateformes). Le Web tient tout entier sur une économie du gratuit, et les plateformes sont prises en étaux entre le travail gratuit de développement et le travail gratuit de production de données, eux-mêmes dépendants des plateformes qu’ils enrichissent.

🔗 les versions historiques du web

«  La somme de travail bénévole et de mobilisation passionnée qu’a reçue Internet depuis sa création est si importante qu’elle n’aurait jamais pu être obtenue dans le cadre marchand d’un travail rémunéré »[^2] (p.65)

Économie du logiciel libre

Le logiciel libre a eu un impact conséquent sur le développement des entreprises. Les entrepreneurs parlaient de « LAMP » (Linux, Apache, MySQL et PHP), un sigle pour désigner les 4 dépendances gratuites qui allaient leur permettre de mettre en place leur infrastructure numérique. Aujourd’hui, les plateformes comme GitHub (2008) permettent aux internautes développeurs de constituer et de contribuer à des nombreux projets.

« Grâce aux licences permissives, des sociétés telles que Facebook ou Instagram ne sont pas obligées de payer pour ce code, mais sont libres d’en profiter grassement. Ce n’est pas différent d’une entreprise de transport (Instagram) qui utilise les infrastructures routières publiques (code public) pour acheminer ses produits à des fins commerciales (application Instagram). »[^1]

Ainsi, les GAFAM et toutes les autres entreprises du web profitent du code libre, généralement fournit par une équipe de développeurs bénévoles soumis aux plateformes comme GitHub, GitLab.

🔗 histoire de OpenSSL, les bénévoles qui sécurisent le web

« Les plateformes d’intermédiation ne produisent pas un service substantiel (comme de fabriquer les contenus de programmes), mais procédural : agréger de la méta-information ou opérer de la mise en relation »[^2] (p.54)

Facebook, Google, Twitter et les autres sont de purs algorithmes, des agrégateurs de données. Ce sont des databrokers, des coutiers de la donnée. Leur travail est de valoriser un contenu pour rassembler une communauté autour d’un mode de partage : leur domaine touche tout ce qui peut être enregistré ou partagé et c’est là où ils vont mobiliser leurs équipes en utilisant du code « externe » (très souvent libre) pour s’occuper du reste : interface, sécurité, compatibilité etc..

L’open source présente de nombreux avantages pour les entreprises :

  • moins cher à développer et potentiellement plus stable ;
  • ouvert à la personnalisation (fork de projets à réinvestir à volonté) ;
  • facilite la portabilité des développeurs d’une entreprise à l’autres : les bibliothèques et outils les suivent depuis Internet.

Ces entreprises se sont elles-même mises dans le bain du logiciel libre en proposant leurs propres librairies et frameworks comme AngularJs (Google) ou Bootstrap (Twitter). Elles profitent ainsi des échanges entre leur développeurs et d’autres bénévoles et en contre-partie offrent également leur travail aux internautes.

Culture métier

Ce travail de développement bénévole (en plus du travail rémunéré, effectué sur les heures d’emploi) devient même un critère d’embauche : la  capitalisation des ouvrages collaboratifs (largement encouragée par les visualisations présentées sur les pages de profil GitHub et GitLab) est un critère pour un employeur. La culture métier des développeurs les rend dans une certaine mesure obligés de partager une partie de leur travail. Ils ne vont pas nécessairement sur des grands projets de libraires : il peut s’agir d’extraits de code sur CodePen.

Ainsi, GitHub, CodePen, Stackoverflow etc. sont des plateformes de partage, mais aussi de comptabilité de la compétence, ou au moins de l’implication, des développeurs. Pour les graphistes et designers c’est Behance, Dribbble.

C’est une opportunité pour les projets de se développer rapidement avec une main d’œuvre large et volontaire. Cette main d’œuvre est aussi volatile qu’intéressée : les contributeurs sont attirés par des projets qui pourront leur donner de la visibilité en plus de proposer un service intéressant qui sera rapidement remplacé. Tout cela donne une masse de code potentiellement non aboutie reposant probablement sur des dépendances de plus en plus instables. En parallèle de cette euphorie, les développeurs mobilisés sur les couches profondes avec des logiciels parfois vieux de plusieurs décennies doivent nous prendre pour des fous.

« Avec l’explosion du nombre de nouveaux développeurs qui utilisent du code partagé sans contribuer en retour, nous construisons des palaces sur une infrastructure en ruines. »[^1]

Hier c’était l’utopie des entreprises fondées dans un garage et aujourd’hui tout le monde peut devenir développeur en allant chercher des guides sur le Web. Le Web a une formidable capacité de s’auto-reproduire en formant ses futurs développeurs. Des entreprises (notamment des écoles privées) profitent également de ce mouvement d’apprentissage du code pour vendre des prestations.

Économie de la donnée

Tout le matériel des entreprises de la données comme les GAFAM et les plateformes de contenu doit être produit (gratuitement par les internautes) et c’est en proposant l’hébergement et les outils de création de contenus que ces plateformes garantissent l’utilisation de leur service. Leur objectif est de fédérer des utilisateurs pour introduire notamment de la publicité, mais récolter toutes sortes de données d’utilisation.

🔗 économie documentaire des réseaux sociaux

De l’autre côté, les internautes profitent de puissants outils de création et valorisation de leur contenu. Internautes et plateformes sociales fonctionnent en un cercle vertueux. L’on pourrait presque s’en réjouir à condition de perdre tout sens moral et éthique.

On pourrait juger le « travail » de ces agrégateurs comme faux, automatique, ne les voir que comme exploitant le vrai « travail » des internautes, créatif. C’est selon Dominique Cardon un point de vue « industriel » : on accorde de la valeur à une unité (le contenu : le poste et sa donnée) plutôt qu’à ce qui constitue réellement le web : la mise en relation d’entités qui prennent des formes très variées. Les unités n’ont pas de sens sur le web, une donnée seule ne vaut rien ; il est nécessaire d’effectuer un travail de valorisation. La plus-value sur le web et en industrie sont deux logiques radicalement différentes.

« À ne pas prendre au sérieux l’importance cruciale prise aujourd’hui par les procédures d’intermédiation (hébergement, agrégation, classements, algorithmes, etc.), on risque toujours de penser qu’il suffirait d’agir du côté des plateformes, ou d’en créer de nouvelles d’un claquement de doigts, pour se libérer de la captation indue de plus-value par les GAFA […] Sans effet réseau, sans artefact de mise en relation, sans algorithme de recommandation, sans métrique de visibilité, nos productions numériques ne seraient plus du travail extorqué, mais elles auraient aussi perdu leur visibilité, leur réputation, les gratifications de l’échange et les honneurs du commentaire, bref, elles seraient sans aucune valeur, ni monétaire ni symbolique »[^2]

[^1]: Nadia Eghbal, Sur quoi reposent nos infrastructures numériques ?, 2017 [^2]: Antonio Casili, Dominique Cardon, Qu’est-ce que le digital labor ?, 2015

travailler la complexité

id : 20200508093223
dernière édition :
type : architecture
mots-clés : informatique, gestionprojet

🔗 complexité

Face à un système trop complexe, nous avons deux postures possibles : simplifier ou décomposer.

Travailler la complexité ne consiste pas nécessairement à rendre un système plus simple ou plus facile. Il faut s’adapter en fonction des besoins. Le simplifier revient à le transformer. C’est utile pour vue 🔗, une abstraction 🔗. On applique une méthode globale à un système quitte à perdre des subtilités. On l’appréhende selon un point de vue choisi. Cette pratique peut aussi objectivement sur-complexifier le projet (si elle n’est pas adaptée). C’est difficile de faire simple.

« L’écologie de l’action c’est en somme tenir compte de la complexité qu’elle suppose, c’est-à-dire aléa, hasard, initiative, décision, inattendu, imprévu, conscience des dérives et des transformations »[^1]

Lorqu’il n’est pas possible d’accepter cette perte d’informations, il faut décomposer le système (réduire en systèmes simples, mais pas simplifés). On peut adopter les méthodes présentés ci-après.

« Un système complexe n’est pas directement décomposable sous peine de détruire son intelligibilité. Il est quasi-décomposable, lorsqu’on peut y identifier des sous-systèmes quasi isolés reliés entre eux et avec l'environnement. »[^2]

🔗 organisation, structure et système

Réductionnisme

Ces deux principes s’appliquent dans une logique du réductionnisme cartésien. Il s’agit de décomposer un problème complexe en « sous-problèmes » plus simples. Cette échelle de décomposition ne vise pas à « simplifier », mais à « décomplexifier », jusqu’à ce que le problème soit si simple que quelques fonctions peuvent y répondre : pour chaque « sous-problème » on met en place une solution. Réaction en chaîne : l’ensemble des solutions (les parties) va répondre au problème complexe global (le tout).

🔗 vue

Cette méthode entraîne toutefois un isolement des différents métiers engagés dans le développement (intégration, génie logiciel, design etc.) et il est probable pour les décompositions les plus importantes qu’il y ait des pertes d’information étant donné que le processus n’est plus linéaire. Le théorème de Bellman précise « L’assemblage des pièces optimisées ne conduit pas à un ensemble optimisé ». En effet, l’assemblage est lui-même une question d’optimisation importante.

🔗 modélisation de l'architecture d'un logiciel

Holisme

« Le tout est plus que la somme des parties » a écrit Aristote dans sa théorie du holisme. De plus, il est difficile de gérer le passage du tout à ses parties. Il est donc important lors de cette scission de veiller à l’intégrité de l’ensemble par une vue globale. Pour cela on va faire abstraction du système global tel une « boite noir » et se concentrer sur les interactions avec son environnement. Quand on combine les deux on se retrouve à évaluer les « propriétés émergentes » des différentes parties du système, mais vu depuis le tout, depuis sa globalité.

Trouver une solution

Deux autres approches contradictoires à croiser cette fois pour approcher une solution.

Téléologie

Selon le principe téléologique de Aristote et Platon, « le but à atteindre est la cause de l’état futur ». Cette approche s’intéresse à la sortie, à l’objectif à atteindre, comme déterminant ce doit être mis en place comme traitement. Après un audit on est amené à déterminer les fonctionnalités à développer. La mise en place du système arrive dans un second temps.

Mécanisme

Selon le principe mécaniste de Copernic et Newton, « l’état courant est la cause de l’état futur ». La sortie (l’état futur) d’un système est donc prévisible car son entrée et son traitement ont été mis en place avant le fonctionnement (ils sont l’état courant). Cette vision va par inférence conduire à (re)définir une solution donnée. Peut être qu’un mécanisme existant répond déjà à ce besoin.

[^1]: Edgar Morin, La Vie de la vie, 1980 [^2]: Serge Diebolt, Le petit lexique des termes de la complexité

triplet RDF

id : 20200915101659
dernière édition :
type : inscription
mots-clés : scienceinformation, websemantique

Le triplet permet d’exprimer la relation entre des ressources afin de former des graphes (visuels ou purement sémantiques) entre elles et ainsi de les exploiter dans des opérations massives réticulaires.

Un triplet se compose de trois éléments :

graph LR
sujet --> predicat --> objet
  • sujet : ressource décrite
  • prédicat : propriété (métadonnée) appliquée au sujet
  • objet : autre ressource liée au sujet selon le prédicat

Ces trois éléments peuvent être de trois types :

  • URI : 🔗 URI, uniform resource locator ;
  • nœud anonyme : ressource sans URI, ne pouvant être localisée que localement dans le graphe ;
  • littéral : chaîne de caractères, nombre, date etc..

Un sujet peut être un URI ou un nœud anonyme. Un prédicat ne peut être qu’un URI. Un objet peut être un URI, un nœud anonyme ou un littéral.

🔗 objet informatique

Exemples

La proposition « Léonard de Vinci a peint la Joconde » met en relation deux ressources, « Léonard de Vinci » et « la Joconde ». Elles sont liées par la propriété « a peint ». Ces trois entités forment le triplet suivant :

graph LR
sujet[Léonard de Vinci] -->|a peint| objet[la Joconde]
  • La Joconde : https://fr.wikipedia.org/wiki/La_Joconde
  • appartient à : https://schema.org/owns
  • Léonard de Vinci : https://fr.wikipedia.org/wiki/L%C3%A9onard_de_Vinci
graph TD
delacroix[Eugène Delacroix] -->|est auteur de| peinture_liberte[La liberté guidant le peuple]
hugo[Victor Hugo] -->|est contemporain de| delacroix
delacroix -->|est mort à| paris[Paris]
hugo -->|est mort à| paris
paris -->|est un| ville
louvres[Louvres] -->|est un| musée
louvres -->|se trouve à| paris
peinture_liberte -->|se trouve à| louvres
peinture_joconde[Joconde] -->|se trouve à| louvres
peinture_liberte -->|est un| peinture
peinture_joconde -->|est un| peinture

typographie

id : 20200712214549
dernière édition :
type : inscription
mots-clés : typographie, lectureecriture

« La typographie est soumis à un but précis : le message imprimé ». « Technique, précision et ordre trouvent leur expression dans la typographie ». Elle est « un travail formel et fonctionnel » dans la mesure où « la production mécanique des caractères et la mise en page selon un système de mesure précis [exigent] une construction rigoureuse et des rapports clairement établis »[^1]

🔗 règles typographiques

Emil Ruder écrit ensuite que la mission de la typographie est d’ordonner l’accumulation d’« inscriptions qui submergent notre monde »[^1].

🔗 la typographie comme interface

Rythme

Emil Ruder insiste sur l’importance du rythme dans la conception typographique, soit la gestion de l’espace (format document, blanc « vide », gris typographique). Il faut « s’éloigner du schéma rigide et éviter la monotonie des répétitions »[^1] si l’on veut rendre la composition vivante et lisible.

Un rythme implique un contre-rythme et donc la forme typographique implique une contre-forme (inimprimée, sans encre) typographique. Le blanc et le noir forment tous deux la lettre.

Pratique contrainte

Dans la chaîne

« Le typographe doit donc bien être conscient qu'il accepte dans le métier d'imprimeur une place où, d’une part, d'autres que lui ont déjà déterminé une partie du travail (caractère, papier, couleur, outils, machines) et où, d'autre part, il devra rendre son ouvrage apte à être soumis à d'autres procédés (impression, façonnage des imprimés). »[^3]

Ajustement optique

« L’œil a tendance à agrandir tous les éléments horizontaux et à minimiser les parties verticales »[^1]

Ainsi le dessin des caractère doit prendre en compte ces problèmes d’illusion optique.

[^1]: Emil Ruder, Typographie, 1981

UML

id : 20210301205211
dernière édition :
type : modélisation
mots-clés : projet

🔗 modélisation de l’architecture d’un logiciel

L’UML est un langage de modélisation orientée objet 🔗. Il couvre de nombreux aspects du développement[^2] grâce à 14 diagrammes 🔗 (ou plus précisément ordinogrammes 🔗, algorigrammes) traitant à la fois la structure 🔗 et le comportement 🔗 des logiciels.

  • (architecture structurelle, « statique »)
    • diagramme de paquetage
    • diagramme de classes (ou structurel) : « décrit la structure d’un système par un ensemble de classes et de relations »[^2]
    • diagramme d’objets : « vue statique des instances des éléments apparaissant dans un diagramme de classes »[^2]
    • diagramme de structure composite
    • diagramme de composants : « Un composant correspond généralement à une ou plusieurs classes ou interfaces » regroupées « sous forme de paquetage »[^2]
    • diagramme de déploiement
    • diagramme de cas d’utilisation : « ensemble de scénarios et d'acteurs, le comportement d'un système en face d'un utilisateur […] par qui et dans quel cas un système est utilisé »
  • (architecture comportementale, « dynamique »)
    • diagramme d’activités : « décrit l’enchaînement des activités […] d’un système en fonction de ses états et ses événements »
    • diagramme de statemachine
    • diagramme de communication (ou collaboration) : « représente les interactions entre les différents objets qui constituent le système et les messages qu'ils échangent entre eux »[^2]
    • diagramme de séquence : « décrit l’échange de messages entre les objets intervenant en tenant compte du séquencement chronologique de messages »
    • diagramme de temps
    • diagramme de vue d’ensemble d’interaction
    • profil diagramme

Ce nombre a été entendu à 23.

« diagramme seul ne représente en général qu’une facette du système construit »[^2]

Relations

L’UML permet de définir quatre types de relation entre des éléments[^1] :

  • relation d’association (relation structurelle) : formalisée par un trait plein ;
  • relation de spécialisation/généralisation : formalisée par une flèche fermée ;
  • relation de réalisation : formalisée par un trait discontinu avec flèche fermée ;
  • relation de dépendance : formalisée par un trait discontinu.

Diagramme de paquetage

Il s’agit de définir l’organisation des répertoires et la liste des éléments qu’ils contiennent. On peut ainsi évaluer l’espace de nom (des fichiers, par type).

🔗 namespace, espace de nom

Connecter des répertoires permet de prescrire les cibles (comme dépendances) des fichiers du répertoire source, ainsi que les emboîtements de répertoires.

flowchart TD

subgraph root
    index.html -. use .-> assets
    
    subgraph assets
        main.js
        main.css
	end
	
	subgraph core
		index.php
	
        subgraph model
        	db.php
            user.php
            file.php
        end
        
        subgraph view
        	userlist.php
        	fileupload.php
        end
        
        subgraph controller
        	auth.php
        	dowload.php
        end
        
        view -. use .-> controller
        controller -. use .-> model
	end
end

Diagramme de classes et d’objet

Il s’agit de présenter les attributs, méthodes, ainsi que les relations des différentes classes (et par extension de leurs instances).

[^1]: Olivier Capuozzo, UML - Les quatre types de relations, 2003 [^2]: Abbas Messaoud, L'environnement FoCaLiZe au service d'UML/OCL, 2018

URI, uniform resource locator

id : 20200915103106
dernière édition :
type : architecture
mots-clés : websemantique

L’URI (Uniform Resource Locator), « identifiant uniforme de ressource », permet d’identifier précisément des ressources au sein d’une base. Un URI doit être unique au sein de son espace de nom 🔗.

Inscription

Un URI est une chaîne de caractère pouvant prendre l’apparence :

  • d’une URL (Uniform Resource Locator) : identifiant d’une ressource sur un réseau, donnant le chemin d’accès ;
  • d’un URN (Uniform Resource Name) : identifiant d’une ressource par son nom, sans indiquer son chemin d’accès ;
    • comment l’ISBN (International Standard Book Number) : identifiant d’un livre etc.

Exemples d’URI[^1] :

  • https://myllaume.fr/ : URL qui identifie la ressource « page d’accueil du site de Guillaume Brioudes »[^1] et « implique qu'une représentation de cette ressource peut être obtenue via le protocole HTTP »[^2], indiqué en début de chaîne ;
  • https://myllaume.fr/#contact : URL qui identifie la ressource « formulaire de contact »
  • mailto:guillaume.brioudes@myllaume.fr : URL qui identifie la ressource « boîte mail de Guillaume Brioudes » via le protocole « mailto » ;
  • +33 1 234 567 890 : URL qui identifie la ressource « numéro de téléphone » ;
  • /Users/guillaumebrioudes/documents/fiche.md : URL sous forme de chemin absolu de fichier qui identifie la ressource « fiche.md » ;
  • 978-2-36405-155-5 : URN qui identifie le livre La documentation dans le numérique de Olivier Le Deuff.

Encodage

L’URI dérive de l’IRI (Internationalized Resource Identifier), c’est une chaîne de caractère unique et pouvant être inscrite avec les lettres de nombreuses langues du monde (caractères à accent, cyrillique etc. venant de l’Unicode), bien qu’il faille parfois encoder la chaîne pour la transmettre :

🔗 encodage du texte

const uri = 'https://mozilla.org/?x=шеллы';
const uriEncoded = encodeURI(uri); // = "https://mozilla.org/?x=%D1%88%D0%B5%D0%BB%D0%BB%D1%8B"

let foo = decodeURI(uriEncoded); // = "https://mozilla.org/?x=шеллы"

[^1]: Cette description est à expliquer via une ontologie pour que le processus puisse être automatique pour les machines [^2]: Wikipédia, Uniform Resource Identifier

utilisabilité logicielle

id : 20210603163025
dernière édition :
type : processus

Il s’agit d’étudier (pour mesurer, améliorer) l’usage que fait un humain d’une interface machine avec des critères comme la rapidité d’utilisation mais aussi le ressentis subjectif de la personne. Elle dépasse les attentes de l’acceptabilité logicielle, l’évaluation consistant à valider que le logiciel répond au besoins de l’utilisateur (coût, fiabilité, compatibilité… utilité : atteindre des objectifs donnés).

L’expression user friendly est insuffisante. Elle est « inutilement anthropomorphique - les utilisateurs n’ont pas besoin que les machines soient amicales avec eux, ils ont simplement besoin de machines qui ne se mettent pas en travers de leur chemin lorsqu’ils essaient de faire leur travail »[^2] (p.23). Elle est ne présente que partiellement le problème, puisqu’il ne s’agit pas que de convivialité et que bien d’autres dimensions entrent en jeu, « un système qui est ‹ convivial › pour l’un peut sembler très fastidieux pour un autre ».

Domaine

L’utilisabilité logicielle regroupe de nombreux domaine de métiers parmi lesquels l’IHM (interface homme-machine), l’UX design (design d’expérience utilisateur), la conception centrée sur l’utilisateur, l’ergonomie logicielle…

« L’utilisabilité est le niveau de facilité, d’efficience, d’efficacité et de satisfaction avec lequel un utilisateur emploie un produit pour réaliser une activité précise »[^1]

Jakob Nielsen résume cette approche[^2] (p.26) :

  • facile à apprendre
  • facile à utiliser, efficace (haut niveau de productivité)
  • facile à se rappeler (pas besoin de réapprendre)
  • peu d’erreurs (aide éventuelle)
  • plaisant à utiliser

Jakob Nielsen donne de très nombreux exemples[^2] où une interface n’a pas été suffisamment bien pensée pour des humains avec un coût de compensation immense :

  • (p.2) des boîtes de dialogues où il n’était possible que de faire apparaître une seule ligne pour un message d’erreur ainsi tronqué. Il a semblé évident aux développeur que les usagers allaient appuyer sur le touche F1 (« aide ») du clavier pour afficher le message d’erreur complet. Hors les usagers ont tout ce temps tenté de comprendre le problème cachée derrière ces brefs messages.
  • (p.3) une entreprise a économisé plus de 500.000 dollars australiens en adaptant ses formulaires pour y éviter les erreurs (en moyenne plus de 7, rattrapées par le personnel).

Niveaux d’utilisation

Jakob Nielsen différencie[^2] (p.44) plusieurs niveaux d’utilisateur logiciel 🔗. Il distingue les utilisateurs experts des utilisateurs novices. Les experts sont à la fois très compétents dans le domaine d’utilisation du logiciel (on parle souvent de logiciels métiers) et avec une culture informatique extensive : ils ont appris à apprendre à utiliser certains types d’interface. Les novices sont au contraire peu compétents dans ces deux champs de compétences. Ils connaissent peu ou pas les terminologies (notions et leurs désignations) et ont des difficultés de compréhension de l’outil informatique.

Il faut garder de la distance avec l’idée de répartir des populations d’utilisateurs en niveaux intermédiaires. Jakob Nielsen différencie deux extrêmes entre lesquels on trouve tout de même une porosité : « les catégories d'utilisateurs se chevauchent. Les connaissances augmentent avec la pratique et diminuent avec la négligence. Un expert dans une partie du du programme est un novice dans une autre »[^3] (p.34). La question ne porte peut-être finalement pas sur les statuts de l’un et de l’autre (« Quelle efficience peut atteindre un utilisateur expert ? », « Comment apporter de l’aide à l’utilisateur novice ? ») , mais plutôt sur la porosité de ces statuts (« En quoi l’œil neuf du novice est-il une opportunité pour apprendre à utiliser l’interface ? », « Quelles sont les faiblesses par négligence de l’expert ? »).

On découvre dans l’analyse des limites qui séparent les archétypes, plutôt que de se concentrer sur eux, des idées comme celle de l’utilisateur occasionnel. Il est pris dans une bascule permanente entre réapprendre et réoublier jusqu’aux concepts d’utilisation. Aussi, il est intéressant de voir un utilisateur expert dans un domaine se projeter sur un autre logicie. On doit l’aider à réadapter ses connaissances et ses paradigmes 🔗 à un nouvel outil.

« les utilisateurs expérimentés auront une idée des fonctions à rechercher […] l’expérience d’un utilisateur en matière de programmation déterminera dans une large mesure dans quelle mesure cet utilisateur peut utiliser des macrolangages et d’autres moyens complexes de combiner des commandes »[^2] (p.46)

Compétences de l’utilisateur

Le logiciel ne peut apporter seul les compétences de son utilisateur. Toutefois, il peut compenser, instaurer un rapport d’équité entre les usagers pour que tous arrivent au même niveau de maîtrise (par l’incitation). On pense souvent à l’exemple des raccourcis clavier. Les utilisateurs les plus avancés vont rapidement aller chercher ce gain d’efficacité dans les logiciels qu’ils utilisent contrairement aux novices.

Certaines interfaces walk-up-and-use sont conçues pour les utilisateurs novices[^2] (p.44). Elles limitent les fonctionnalités et méthodes pour les experts avec des interfaces minimalistes (en interaction et contrôle) afin de faciliter l’entrée des novices. C’est un nivellement par le bas. Ce sont par exemple les interfaces de commandes dans les espaces publics. Les interfaces d’installation d’un logiciel vont parfois proposer un « mode avancé » et ainsi proposer une bifurcation dans le défilement des champs de la boîte de dialogue.

D’autres interfaces sont moins accessibles, nécessitent une formation importante avant de pouvoir être utilisées, même à un niveau basique. Elles permettent aux utilisateurs experts d’avoir une efficacité de travail très importante. Les utilisateurs les plus avancés peuvent être lassés par un outil qui leur demande des manipulations à leurs yeux devenues négligeables. Là on est tenté de leur laisser choisir un mode d’utilisation avancé.

Face à la complexité

La complexité 🔗 du logiciel ne vient pas nécessairement de l’interface ; l’idée même du logiciel métier, devant couvrir un domaine de métier, impose un système à ses utilisateurs.

« la réalité est que la plupart des gens n’acquièrent pas une expertise complète de toutes les parties d’un système, quelle que soit l’intensité de leur utilisation […] un utilisateur donné n’en utilise qu’un petit sous-ensemble »[^2] (p.45)

Un utilisateur face à de nombreuses options est mis en difficulté, le moins est plus profitable, le mieux est l’ennemi du bien. Chaque fonctionnalités est un concept de plus à comprendre dans un ensemble d’options et ce sont autant d’évaluations à effectuer pour un utilisateur[^2] (p.15). Des spécialistes ont qualifié de fatwares les logiciels qui gonflent de version en version afin de répondre à tous les cas d’utilisation.

« la plupart des logiciels ont plus de fonctions que les utilisateurs n’en auront jamais besoin ou qu’ils ne pourront jamais apprendre »[^2] (p.9)

Un formateur devra maîtriser le logiciel complètement et avec un haut niveau.

La métaphore, l’analogie, est un outil puissant pour répondre à la complexité logicielle. Les visuelles sont les plus percutentes.

« Méfiez-vous des métaphores inventées qui peuvent fonctionner pour expliquer un seul concept, mais qui empêchent de relier ce concept à d'autres et bloquent ainsi la poursuite de l’apprentissage »[^3] (p.46)

Erreur utilisateur

« Les utilisateurs ont un potentiel infini pour faire des erreurs d’interprétation inattendues des éléments de l’interface et pour effectuer leur travail d’une manière différente de celle que vous imaginez »[^2] (p.10)

Les concepteurs confondent leur culture technique avec celle de leurs utilisateur. Pour cause, ils ont le même environnement de travail[^2] (p.13) (un humain qui utilise une machine à travers un écran), si bien que la culture technique générale et spécifique au logiciel semblent aller de soi. Hors, le concepteur doit rester humble lorsque il conçoit une interface. Il doit remettre en question le moindre de ses choix avec des tests auprès d’utilisateurs. Il ne peut pas désapprendre ce qu’il sait des concepts du logiciel.

Les utilisateurs ne savent pas ce qui est bon pour eux, préfèrent ne pas changer leurs habitudes quand on leur propose autre chose.

« si les utilisateurs ont des problèmes avec un aspect de l’interface, ce n’est pas parce qu’ils sont stupides ou qu’ils auraient dû faire un peu plus d’efforts »[^2] (p.11)

Personnalisation

On pourrait penser que parce qu’on permet à une personne de personnaliser son interface, elle va faire les meilleurs choix pour elle[^2] (p.12-13). Hors, non seulement l’interface de personnalisation elle-même est une interface qui ne peut être adaptée par l’utilisateur, mais elle demande aussi une bonne compréhension des concepts du logiciel ; elle ne facilite l’approche de l’interface que si elle ne permet que de faire des choix cohérents avec ces concepts.

Proposer plusieurs modes d’utilisation de la même interface (pour l’adapter aux utilisateurs) ne simplifie pas nécessairement l’usage. Les utilisateurs ont tendance à oublier dans quel mode il se trouve « et commettent des erreurs en faisant la bonne chose au mauvais moment » [^3] (p.33). Ils perdent leurs repères d’un mode à l’autre, peuvent sur/sous-estimer leurs capacités.

Documentation

La présence d’un manuel d’utilisation 🔗 ne valide pas la mise en place d’outils et concepts complexes au sein du logiciel[^2] (p.148). Les utilisateurs doivent pouvoir utiliser le logiciel sans recourir à la documentation. Aussi, ce document constitue en lui-même une complication du logiciel. Il s’agit d’une nouvelle interface qui nécessite l’ajout de fonctionnalités (de navigation, de lecture) radicalement différentes de ce que propose le logiciel. Il s’agit quasiment d’un logiciel dans le logiciel, nécessitant son propre mode d’emploi (en introduction) s’il s’avère complexe. Devoir éditer un méta-manuel (une documentation pour pouvoir utiliser les différentes documentations) du logiciel est un avertissement : il y a un excès de complexité. Cela ne vaut pas pour une documentation intégrée à l’interface du logiciel 🔗.

Latence

La latence est le délais de communication entre des machines, des systèmes. C’est le temps à attendre par exemple pour le chargement d’un fichier. L’utilisateur est prêt à attendre pour certaines tâches qu’il estime lourde pour la machine, comme la copie d’un fichier. Il accepte ce temps, parce qu’il s’y attend. Ainsi, pour faire accepter la latence à un utilisateur, il faut lui faire sentir que son action à du poids, qu’il en coûte en performance. On limite l’anxiété des personnes avec des machines moins puissantes, laquelle peut être la plus nuisible à l’expérience utilisateur[^4]. Il faudrait permettre à l’utilisateur pour les opérations longues et bloquantes d’annuler leur execution pour qu’il puisse reprendre la main[^3] (p.75).

[^1]: Nicolas Alarcon, Usez, abusez de l’utilisabilité !, 2015 [^2]: Jakob Nielsen, Usability Engineering, 1993 [^3]: Wiliam Horton, Designing & writting online documentation, 1990 [^4]: Raymond Nickerson, Man-Computer Interaction, 1969

valorisation de contenu numérique

id : 20200702145334
dernière édition :
type : processus

Selon Franck Cormerais, la valorisation est une « opération d’adoption d’un système de valeurs et de ses représentations »[^1]. Il explique que c’est par la valorisation que l’on fait l’expérience de l’objet technique, que c’est par son introduction dans un système et sa représentation typo·graphique que l’on peut appréhender cet objet.

🔗 visualisation

[^1]: Franck Cormerais, Humanités digitales et (re)organisation du savoir, 2014

variables et constantes

id : 20210427194405
dernière édition :
type : programmation

Les variables et constantes sont des marques substitutives. Elles remplacent dans le flot de contrôle 🔗 différentes valeurs auxquelles on applique des opérations. Par leur identifiant, elles intègrent un espace de nom qu’il est nécessaire de connaître/transmettre pour pouvoir les utiliser.

Caractéristiques

Une variable possède plusieurs caractéristiques :

  • nom : identifiant ;
  • type : chaîne, entier, flottant, booléen, fonction 🔗, classe, objet 🔗… ;
  • valeur : correspondant à son type et pouvant être variable ou constante ;
  • adresse : endroit dans la mémoire où il est stocké ;
  • portée : globale ou non : portion de code source d’où il est accessible 🔗 ;
  • visibilité : ensemble de règles qui fixe qui peut l’utiliser.

Selon le langage, ces caractéristiques peuvent être limitées, voire ignorées. Par exemple, on différencie souvent les langages au typage fort ou faible (avec lesquels il est possible d’assigner toute valeur à une variable sans en préciser le type, même s’il venait à varier).

L’informatique ne tolérant pas les ambiguïtés, chacun des identifiant doit être unique, bien que les interpréteurs peuvent accorder une certaine souplesse, par exemple quant à la casse.

Cycle

Voici les étapes successives de création et d’utilisation d’une variable :

  1. déclaration : création de l’identifiant, elle a lieu une fois ;
  2. définition : associe une zone mémoire pour le stocker (elle a en général lieu en même temps que la déclaration) ;
  3. affectation : attribution d’une valeur (elle a en général lieu en même temps que la déclaration, mais peut elle être effectué plusieurs fois, sauf pour les constante) ;
  4. lecture/appel : utilisation de sa valeur ;
  5. suppression de la valeur, automatiquement ou pas une instruction.

Signification

Le nom des variables est une réflexion à part entière pour donner à ce texte de substitution un sens. Elles intègre un espace de nom 🔗 qui doit rester cohérent, progresser dans la logique d’un dictionnaire, d’un lexique. Il pourra évoluer tandis que le sens suggéré par les variables restera le même. J’utilise fréquemment les formes suivantes :

  • is_active pour remplacer un booléen (true ou false) affirmant ou infirmant la proposition « est actif ».
  • elts pour un tableau contenant des éléments, chaque unité étant remplacé par un elt une fois dans la boucle de traitement

Des variables portent aussi un nom utile pour leur utilisation plutôt que pour la compréhension de leur sens. Ce sont les variables métasyntaxique. C’est le cas de la variables toto (et ses variantes tata, titi… ou la version anglaise foo et bar, « fucked up »). C’est aussi le cas des variables à un lettre comme le i. Il représente l’index durant les itérations. Non seulement c’est un nom conventionnel, mais en plus il est très court et permet de faire des référence aux éléments d’un tableau de manière concise :

for($i=0 ; $i < 5; $i++){
    $elt =$elt[i];
}

versionnement Git

id : 20200707101208
dernière édition :
type : processus
mots-clés : projet, technique

Git est un VCS, un logiciel open source de Version Control System, de versionnement (versionning). Il permet de dresser un historique de chaque fichier de l’arborescence du logiciel qu’ils soient fichiers sources ou élément de l’environnement de développement 🔗. Cet historique est jalonné de versions établies de l’ensemble de l’arborescence. On peut enregistrer un nouveau jalon (enregistrement d’une nouvelle version de l’arborescence) pour toute modification dans l’ensemble : ajout, modification, suppression de tout ou partie d’un fichier.

Partant d’un jalon (commit), il est possible d’effectuer plusieurs actions, parmis lesquelles :

  • abandonner (discard) les modifications depuis le dernier jalon ;
  • revenir en arrière (revert), au stade du jalon précédemment enregistré ;
  • mettre de côté (stash) les modifcations
  • diviser (branch) l’historique en une parallèle (branche) pouvant fusionner (merge) avec ses sœurs ;
  • bifurquer (fork) l’historique pour obtenir une nouvelle arborescence pouvant fusionner avec sa mère.

Ces fonctionnalités permettent de sauvegarder régulièrement le travail effectué dans un répertoire racine (repository). Elles permettent aussi de diviser ce même espace pour des travaux parallèles. C’est très utile pour programmer à plusieurs, mais c’est aussi à ce moment que les conflits peuvent faire irruption : un certain nombre de fichiers ont été modifiés à un même endroit, par plusieurs contributeurs, sans qu’il aient actualisé et harmonisé leurs modifications. C’est une problématique de git flow 🔗.

Écrire et effacer du code (du texte) sont des actions faciles et rapidement irréversibles. Il devient difficile de naviguer dans l’historique de modification (Ctrl+Z) au-delà d’un certaine nombre d’allés et venus. Le versionnement consolide ce travail en jalonnant cet historique et en bloquant certaines modifications avec des procédures bien formelles et régulières pour les étapes d’inscription du code.

Collaboration en ligne

La mise en ligne de ce système (via des services comme GitHub ou GitLab) permet de mettre en ligne (push) des jalons et de permettre à des collaborateurs de les tirer (pull) sur leur propre ordinateur pour en proposer de nouveaux. Ainsi, Git permet désormais de maintenir la quasi-totalité des logiciels libres et open source 🔗.

Le système de jalon a été étendu pour donner de véritables interfaces de gestion de projet, ainsi que des système de tickets (issues) pour assistance et debug.

visualisation

id : 20200912130028
dernière édition :
type : modélisation
mots-clés : scienceinformation, donnee

Objectif de la visualisation selon Ben Shneiderman :

« Le but de la visualisation est de donner un aperçu, pas des images. »[^1]

On ne crée pas juste un visuel, mais une structure (modélisation) de compréhension pour l’utilisateur. On veut une visualisation que l’on peut voir, mais aussi explorer et ainsi limiter le « fossé de l'évaluation » de l’interface 🔗.

Les représentations visuelles sont plus universelles quand le texte propose des explications plus personnelles. Le schéma nous

Cela peut notamment nécessiter un rendu dynamique, là où le code nous simplifie la tâche : on recours à des variables qui permettent d’instancier 🔗 un visuel, de générer une nouvelle sortie.

[^1]: Ben Shneiderman, Readings in Information Visualization: Using Vision to Think, 1999

vue

id : 20200708121357
dernière édition :
type : modélisation

Une vue est une interface simplifiée en longueur, et non en profondeur, d’un système selon un point de vue propre.

On va ponctuellement ignorer des fonctionnalités (pourtant programmées), des informations (pourtant contenues dans la base) en considérant pleinement le besoin de panorama (volontairement limité) d’un utilisateur.

  • La vue d’un humain : celle d’un développeur n’est pas la même que celle d’un intégrateur, d’un designer ou d’un utilisateur (de différent niveaux et besoins). Parmi les vues : fonctionnelle (transformations), architecturale (composition), sémantique (concepts), dynamique (dans le temps).
  • La vue système : un assemblage de fonctionnalités réunies pour donner un rendu, une interface particulière. Par exemple pour la génération d’une page web avec tels composants, la réunion de données d’une base au sein d’une table.

En adoptant une interface moins complexe, on permet à l’utilisateur de mieux se concentrer sur les informations affichées. La difficulté est dans le passage d’une vue à une autre.

Cas de Notion

Notion est un logiciel propriétaire freemium permettant de gérer des bases documentaires complexes très facilement grâce à un puissant outil de design des données. Depuis une même base de données (selon sa structure), il nous permet de générer une variété de visualisations 🔗, des interfaces faites pour exploiter ces données de différentes manières. Seul l’interface change, les données et leurs structure ne varient pas.

Notion permet de créer des listes de pages et d’ajouter à chacune certaines métadonnées 🔗 comme un label, des tags, une date. Ces métadonnées permettent ensuite à l’utilisateur de trier la liste en fonction de ces informations, mais aussi de filtrer l’affichage, voire de le transformer. Ainsi, une liste de pages datées peut devenir un calendrier, puis revenir à la forme de liste, puis devenir un tableau. Tout est fait pour que l’utilisateur puisse adopter la meilleure vue de ses données selon un besoin précis. D’autres formes de listes sont disponibles et adaptées à des besoins spécifiques comme avec le tableau Kamban pour la gestion de projet.

Cette flexibilité de l’information fait de Notion un outil capable d’accueillir tous les formats d’information et de les disposer sous des formes variées convenant au métier de chacun. Il permet de faire du suivi de projet, des wikis et bien d’autres formes de carnets et tableaux de connaissances.

vue architecture logicielle

id : 20211022151437
dernière édition :
type : modélisation

Les vues 🔗 permettent d’observer l’architecture d’un logiciel 🔗 avec plusieurs points de vue métiers. Par exemple, l’intégrateur (de l’interface) n’a besoin que de visualiser que certains modules 🔗 relatifs à l’affichage quand l’ingénieur a besoin d’une vue d’ensemble de l’ouvrage et non de certains détails qui pourraient intéresser des développeurs attachés à des tâches localisées.

« un architecte de bâtiment fournirait une représentation du bâtiment au charpentier, peut-être une autre au plombier, et encore une autre à l’acheteur »[^1] (p.5)

Le code source 🔗 est la vue initiale. Elle entremêle de tous les points de vue de tous les métiers.

« c’est comme un bâtiment sans peau extérieure et dont tous les détails sont exposés : cela rend la compréhension de l’architecture globale très difficile »[^1] (p.5)

Il faut procéder à des « modulatisations virtuelles » pour regrouper logiquement les artefacts 🔗 utiles à un métier donné. Il est possible de proposer simultanément plusieurs vues. Basés sur le code documenté 🔗, ces vues sont mises à jour automatiquement.

« Comme la maintenance prolongée tend à dégrader la structure des logiciels, il est parfois avantageux de ne pas tenir compte de la modularisation existante basée sur la structure physique du code source. Au lieu de cela, on peut construire des agrégats d’artefacts logiciels basés sur des critères de regroupement et de sélection jugés appropriés pour améliorer la compréhension de l’ensemble du système ou de certains sous-systèmes pertinents »[^1] (p.5) 🔗

[^1]: Scott Robert Tilley, Documenting-in-the-large vs. documenting-in-the-small, 1993

web scraping

id : 20210120151041
dernière édition :
type : architecture
mots-clés : code, scienceinformation

Le web scraping est l’extraction du contenu de sites Web et plus précisément de leur DOM 🔗. On va utiliser des fonctions pour parcourir l’arborescence et capter le contenu de balises ou attributs à l’aide de boucles. On terminera par structurer ces informations pour les réutiliser.

🔗 sérialisation des données

La bibliothèque 🔗 Python BeautifulSoup4 permet de faire du web scraping :

def getHtmlContent(url):
	# fetch raw HTML
	html_content = requests.get(url).text
	# parse html content
	soup = BeautifulSoup(html_content, "lxml")
	return soup

def getTitle(url):
	content = getHtmlContent(url)
	
	print(content.title.text)

getTitle("https://myllaume.fr/")

wiki

id : 20200813132904
dernière édition :
type : processus

Je prends ici l’exemple de Wikipédia, mais ces remarques peuvent s’appliquer à tous les wikis.

Au début des années 1990, l’informaticien Ward Cunningham cherche une solution pour résoudre des problèmes récurrents de de conception en ingénierie informatique. Il décide de créer son propre système de partage des connaissances. « Le 25 mars 1995, Cunningham rend public le premier site wiki dénommé WikiWikiWeb »[^1] (p.2).

« Ses caractéristiques dominantes sont l’altruisme, la collaboration et la négociation entre contributeurs, l’accumulation de connaissances mutualisées et la possible participation de tout un chacun »[^1] (p.2)

🔗 production de contenu web

Ce sont également les valeurs du logiciel libre 🔗.

Autorité

Wikipédia, lancé par Jimmy Wales et Larry Sanger, tire son autorité (la confiance qu’on lui accorde) de la processualité éditoriale 🔗 que sa communauté entretient.

« L’une des originalités de Wikipédia tient au fait que sa politique éditoriale a été définie de manière progressive et collaborative. Après que Wales eut fixé les grands principes normatifs, la communauté a travaillé à l’écriture d’un important corpus réglementaire selon un mode wiki. La rédaction collégiale des règles s’est accompagnée d’échanges et de délibérations entre contributeurs »[^1] (p.1)

Limites

Ce processus d’élaboration des règles en commun fait ses preuves, mais il a ses limites sur la durée :

« l’instauration des règles émane d’une minorité agissante de contributeurs expérimentés qui irait à l’encontre de l’esprit originel du projet […] et conduit à une hiérarchisation et rigidification de la communauté »[^1] (p.4)

Aussi, les règles s’accumulent (« inflation réglementaire »[^1] p.6) et il devient plus difficile d’entrer dans la communauté (« augmentation des coûts d’entrée » p.6), de commencer à contribuer.

« La ‹ crédibilité de la multiplicité › postule ainsi qu’un collectif suffisamment nombreux, collaborant et se corrigeant mutuellement est à même de construire graduellement une source fiable. »[^1] (p.3)

À côté de Wikipédia, l’autre projet de ses créateur, Nupedia était quant à lui élaboré sur un système éditorial scientifique. Le projet tiendra deux ans avec 24 articles publiés, avant d’être abandonné. La formule de Wikipédia fonctionne.

Importance du chiffre

La réputation est importante pour les collaborateurs qui gagnent ainsi en autorité au sein de la communauté. Ainsi le nombre de contribution est un critère fort et il existe un classement des wikipédien·ne·s.

🔗 production de contenu web (#Comptage)

Vandalisme

Les contributeurs malveillants ne pourraient effacer les informations des pages du wiki. Toutes les versions de chaque page sont enregistrées avec l’adresse IP de l’utilisateur qui les a modifié (laquelle peut être mise sur liste noire). L’affichage est en revanche affecté ; il faudra annuler les modifications indésirables.

Rapport à l’Encyclopédie

Dans son tableau « Tableau récapitulatif des tensions wikipédiennes »[^1] (p.5) Gilles Sahut oppose la vision libriste de Wikipédia à la culture plus bureaucratique des encyclopédies. « croissance cumulative » est opposé à « fiabilité », « évolutivité » à « stabilité ». On s’attache d’un côté à ouvrir les procédures et les accès et de l’autre à veiller méthodiquement à limiter méthodiquement les erreurs.

Ainsi dans les différents rapports présentés ci-dessous on observe toujours une tension : une partie de la communauté plus spontanée et ouverte et l’autre plus modérée. Cette division fait aussi la force de Wikipédia et peut faire la force d’autres projets d’une importance moindre mais avec une communauté suffisamment hétérogène.

Sujet et sources

Umberto Eco a défini l’« Encyclopédie Maximale » comme étant composée de « tout ce qui a été dit socialement, c’est-à-dire non seulement ce qui a été accepté comme vrai, mais aussi ce qui l’a été comme imaginaire »[^2]. Wikipédia pourrait tendre vers cela en abordant toutes les thématiques, tous les sujets, et de manière complète. Il existe une tension entre les contributeurs et contributrices « inclusionnistes » contre « suppressionnistes », les premiers souhaitant s’ouvrir à un champ plus large de sujets et de sources tandis que les seconds veulent se limiter à l’académique.

Temporalité

Un wiki peut évoluer en même temps que son sujet tandis que les encyclopédies papiers ne sont imprimées bien moins régulièrement : les années passant dévalorisent leur contenu potentiellement révisé tandis que les pages web des wikis s’actualisent pour tous.

[^1]: Gilles Sahut, Construire une encyclopédie avec un wiki ? Regards rétrospectifs sur la politique éditoriale de Wikipédia, 2016 [^2]: Umberto Eco, De l’arbre au labyrinthe, 2010, p.81

wikilinks

id : 20200622140512
dernière édition :
type : inscription
mots-clés : web, traitementtexte

🔗 wiki

Parmi les standards des langages de balisage légers, on retrouve dans une très grande partie des logiciels la syntaxe, le marqueur typographique, [[page reliée]]. Il permet de mettre en place des liens hypertextes internes entre les pages, et parfois des ancres [[page reliée:ancre]] selon les logiciel d’interprétation comme DokuWiki.

Entre ces double-crochets on ne va pas inscrire une adresse URL, mais l'identifiant unique d'une page afin que, au clic sur le lien, l'utilisateur soit redirigé sur la page en question.

Liens orphelins

La logique des liens des wikis est particulière : comme pour le logiciel Enquire de Tim Berners-Lee ou DokuWiki. Il est nécessaire d’avoir une page source pour créer un lien. Il n’est pas possible (comme on pourrait le faire lorsque l’on édite du HTML) de créer un lien ex nihilo (à partir de rien). On limite ainsi les pages orphelines en justifiant l’extension de la base documentaire et en préservant ses relations logiques.

🔗 hypertexte

zettelkasten, méthode documentaire

id : 20200630153054
dernière édition :
type : documentation
mots-clés : scienceinformation

🔗 processus documentaire

Un Zettelkasten est littéralement une boîte à fiche (base de données de connaissances) produite grâce à une méthode documentaire. Les fiches contiennent des idées et autres informations brèves qui sont enregistrées au fur et à mesure. L’objectif va être de relier et retrouver ces idées afin d’en construire de nouvelles.

« documentation personnelle réticulaire »[^1]

🔗 base de données

On retrouve des systèmes de rangement de fiche dans des tiroirs dès le 16ème siècle[^2] ou du moins des pratiques approchant celles de Niklas Luhmann. C’est la technique de ce dernier que nous avons retenu. Il reconnaîtra lui-même que ce système l’a aidé dans sa rédaction prolifique : 70 livres et 400 articles rédigés à l’aide de ses 90 000 fiches issues de ses quarante années de carrière pluridisciplinaire.

Flux

Zettelkasten est avant tout une méthode de flux.

« Au fur et à mesure que cette base de connaissances s’accroît, le bénéfice pour la recherche d’information et la réflexion augmente aussi »[^1]

« Un zettelkasten est une accumulation de notes dans laquelle chaque note successive se voit attribuer un numéro, plutôt que d’être placée dans une catégorie ou un sujet. Si une nouvelle note se rapporte à des notes précédentes, elle y fait référence (ou s’y lie), et si des notes ultérieures complètent ou modifient la note, elles reçoivent un numéro entre la note originale et celle qui la suit. Ainsi, le preneur de notes ne se préoccupe jamais de la structure globale de son système de prise de notes, qui naît organiquement de l’utilisation, mais uniquement du contenu d’une note individuelle et de son lien avec les autres notes. Les notes clés deviennent des carrefours de liens et de rétroliens ; en fait, la meilleure pratique pour rendre un zettelkasten utile est de rechercher toutes les occasions de relier les notes. Lorsque le preneur de notes examine son zettelkasten en entrant dans le labyrinthe à partir d’une note particulière en rapport avec le sujet auquel il pense ou écrit, il découvre toutes sortes d’idées, d’exemples et de citations associés grâce à l’accumulation de liens - comme si le zettelkasten lui-même trouvait des idées pour lui. »[^3]

Pour arriver à cela, deux points d’attention :

  • s’imposer et respecter une structure simple (sinon on risque de mal l’appliquer, de devoir en changer et ainsi de devoir recommencer).
  • réfléchir en permanence sur sa manière de travailler et concevoir les fiches pour penser pérennité.
  • retravailler régulièrement ses fiches en remettant à l’épreuve son contenu et ses connexions.

Autre remarques traduite de Luhmann issus de l’article de Robert Minto[^3]

  • « un alter ego avec lequel nous pouvons communiquer en permanence »
  • « pas d’ordre construit dans son intégralité, pas de hiérarchie, et surtout pas de structure linéaire »
  • « elle a sa propre vie, indépendante de son auteur »
  • « la boîte à fiches a besoin d'un certain nombre d'années pour atteindre une masse critique »

Jean-François Bert cite Organisation du travail intellectuel de Paul Chavigny :

« Il est indispensable, surtout, d’éviter deux erreurs classiques : ne pas savoir se limiter dans la récolte de ses matériaux (“Si l’on prétend toucher à de multiples questions importantes, il faut s’en tenir aux généralités, ne pas croire qu’on peut approfondir toutes les questions qu’on aborde”) et apprendre à restreindre les subdivisions des rubriques (“Qui aura besoin d’en arriver à un million de divisions ? Une administration peut-être, presque jamais un particulier”). »[^2]

Le Zettelkasten Luhmann de était un meuble et ses fiches du papier. Il a dû s’adapter pour garder un système fonctionnel sur le long terme.

Version analogique

Chaque fiche possède un identifiant écrit selon la place de la fiche dans la base. Une fiche est subordonnée à une autre dans la mesure où elle évoque le même sujet. Par subordination se créer l’arborescence d’identifiant suivante.

.
├── 1
│ ├── 1/1
│ │ ├── 1/1/1
│ │ └── 1/1/2
│ └── 1/2
├── 2
└── 3

Toutefois on ne saurais se contenter d’une arborescence pour organiser la connaissance : le cheminement des idées n’est pas linéaire et procéder ainsi pour les organiser est une perte. Ainsi, il est possible de faire référence à d’autres fiches (référence non-linéaire) en inscrivant leurs identifiants.

De plus, Luhmann utilisait un système de tags pour donner rapidement le sujet d’une fiche et pouvoir organiser sa connaissance de manière inter-disciplinaire.

Version numérique

Quand l’analogique ne permettait pas de disposer d’outil de recherche et de liaison automatiques et profonds, l’informatique assure une aide suffisante pour concentrer les fiches dans une unique répertoire avec pour identifiant la date (horodatage AAAAMMDDHHMMSS) ou bien un UUID (Universal Unique Identifier). On ajoute quelques tags pour la transversalité, le tout dans le YAML Front Matter des fichiers Markdown.

🔗 langages de balisage léger

Vue graphe

Grâce aux liaisons des différentes fiches, il est possible de générer un graphe 🔗 depuis la base documentaire : chaque fiche est un nœud et elles sont reliées selon les liens inscrits.

« [l’intérêt de la vue graph] ne réside pas dans ce qu’elle suggère des connexions entre les savoirs représentés (qui sont éphémères), mais dans sa valeur réflexive. En me donnant une vision d’ensemble, elle m’aide à passer d’une représentation mentale limitée (liens note à note) à une conscience plus globale de la structure documentaire que je suis en train de produire. Par exemple, je constate qu’il existe déjà des notes qui servent de passerelle entre différents champs de savoirs, et cela m’aide à voir l’aménagement qu’il faudrait faire (ouvrir à certains endroits, fermer à d’autres). »[^1]

Critique

« J’ai commencé à m’inquiéter du fait que l’effort considérable qu’impliquait l’utilisation du système primitif de notation papier, stylo et boîte en carton avait en fait été la source du développement intellectuel de mon professeur […] et qu’en rendant le processus si facile pour moi, j’avais sacrifié son principal avantage »[^3]

L’utilisation qui consiste dans un texte à mettre à la suite des fiches n’est pas pertinent. Sans lien entre les idées, le lecteur est perdu faute de liens logique, invisibles sur le papier.

[^1]: Arthur Perret, Visualisation d’une documentation personnelle réticulaire, 2020 [^2]: Jean-François Bert, Une histoire de la fiche érudite, 2017 [^3]: Robert Minto,Rank and File, 2021

Aide

Cliquez ici pour accéder à la documentation de Cosma

Raccourcis

Espace Réactiver l'algorithme de dessin du graphe
S Déplacer le curseur dans le champ Recherche
Alt + clic (sur un type de fiche) Désélectionner les autres types
R Réinitialiser le zoom
Alt + R Réinitialiser tous les paramètres visuels
C Zoomer sur le nœud de la fiche active
F Passer en mode Focus
Echap Fermer la fiche

Myllaume

Guillaumes Brioudes

Fiches sur le développement logiciel dans le domaine de la gestion de la connaissance


Version 1.2.0 • Licence MIT

  • Arthur Perret
  • Guillaume Brioudes
  • Olivier Le Deuff
  • Clément Borel
  • Programme ANR HyperOtlet
D3 v4.13.0
Mike Bostock (BSD 3-Clause)
Nunjucks v3.2.3
James Long (BSD 2-Clause)
Js-yaml v3.14.0
Vitaly Puzrin (MIT License)
Js-yaml-front-matter v4.1.0
Derek Worthen (MIT License)
Markdown-it v12.0.2
Vitaly Puzrin, Alex Kocharin (MIT License)
Minify-html v0.4.3
Wilson Lin (MIT License)
Fuse-js v6.4.6
Kiro Risk (Apache License 2.0)
Moment v2.29.1
Iskren Ivov Chernev (MIT License)