« 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 [[20210304181626]] (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 :

« 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

[[20200526222401]] modèle, pattern

L’abstraction est un exercice d’analyse permettant de travailler dans un système. Cela consiste en la simplification (« Supprimer ce qui n'est pas essentiel »[^3]) d’un ensemble d’éléments vus à travers le prisme de modèles de pensée ou bien de conception. On supprime de l’information pour faciliter une opération.

L’abstraction est une posture intellectuelle face à la complexité [[20210419170156]]. 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]

Classes

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 »[^2]. On isole des qualités d’un objet concret pour les appliquer à d’autres.

En programmation orienté objet [[20200522122316]], 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]: CNRTL, Abstraction [^2]: Wikipédia, Abstraction (Informatique) [^3]: CNRTL, Simplifier

AJAX protocole de requêtes asynchrones

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

[[20210405160832]] requête [[20200704153246]] 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.

[[20210221130228]] 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);
    });
});

[[20200705083336]] 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 [[20210117100240]] 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 [[20200622164608]] 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 [[20200813132904]] 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 [[20200701221037]] des applications Electron [[20210705120100]] 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 [[20200622101202]], 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 [[20210130151200]]. 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

[[20200708132301]] interface

Une API (Application Programming Interface) permet de mettre en relation des programmes[^2] de manière structurée (modulaire [[20210313113130]]). Il s’agit en général d’échanger des données [[20200509195652]] entre deux parties, de faire communiquer des bases selon les principes de l’application [[20200909183033]] : 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)

[[20200701214359]] structures de contrôle

L’utilisation des API dépend de la documentation [[20210118161126]] 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 [[20200704100343]] 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 [[20210412165919]] 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 [[20210418214149]] 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 [[20200701221037]]).

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.

[[20200705114827]] 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.

[[20200802100201]] 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 [[20201224152456]] 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.

[[20200709104849]] rapport aux objets techniques

À l’opposé, nous trouvons les logiciels LOS [[20200710204125]], 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 [[20200705100544]] ; 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

architecte logiciel

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

[[20210531145255]] 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 [[20210419170156]].

« 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)

[^1]: Martin Fowler, Who Needs an Architect?, 2003

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 [[20200708132301]]
  • Controller : gestion des requêtes [[20210405160832]] 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.

[[20210112090725]] 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 [[20210109130837]].

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 [[20200704100343]] 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 [[20200522122316]] pour sécuriser les appels à la base de données.

De nombreux framework [[20200701222949]] 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 » (même si la raison économique gagne ). Elle n’apporte rien aux utilisateurs, clients, c’est une « qualité interne » du projet. Elle permet à l’équipe d’accélérer toujours plus vite dans l’implémentation de fonctionnalités en repoussant la dette technique [[20210109130329]].

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 [[20210412165919]] 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 [[20210313113130]] pour pouvoir prévoir les modifications imprévisibles, c’est ainsi qu’on augmente la complexité du logiciel [[20210313105330]] ;
  • « 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 [[20201224152456]] 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 [[20210419170156]] (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 [[20200704135046]] 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 [[20200508111132]] 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 [[20210326162804]].

Impact

L’architecture détermine l’utilisabilité d’un logiciel [[20210603163025]].

[^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].

[[20210116135423]] 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 [[20210115183034]], 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].

[[20200725133539]] 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 [[20200708132301]]. 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.

[[20200906135907]] 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.

[[20200718172257]] 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

base de données

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

[[20210117094335]] 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 [[20200624194717]] ;
  • 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 [[20210117100240]], normaliser les contenus et mettre en place des systèmes de recherche entre eux à l’aide de métadonnées [[20200923152146]].

Structure par les métadonnées

Dans le cas d’une base de fiches [[20200624194717]], les métadonnées [[20200923152146]] 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 [[20200526222401]] 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 [[20210502102039]] de l’informatique. La programmation orientée objet [[20200522122316]] 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 [[20200622101202]] 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 [[20200915084904]].

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 [[20200704160828]]. Elle s’applique aux fichiers HTML. Cette convention permet de structurer la sélection des objets et donc l’affectation des méthodes (CSS [[20200704152459]] et JavaScript [[20200704153246]]) avec une approche modulaire [[20210421151432]].

Ci-dessous on trouve deux codelets : un extrait de HTML avec la convention de nommage BEM et un extrait de SCSS (langage transpilé [[20200907090751]] 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 [[20210130110228]] 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 [[20201224102746]], 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 [[20200710204125]] et instaurent une « économie de l’écriture »[^1] du code source, un échange continu et collaboratif entre les développeurs.

[[20210326162804]] 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 [[20200701221037]] claire et sont accessibles aux développeurs grâce à leur documentation [[20210118161126]] 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 :

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

[[20200515185607]] 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

[[20201224102746]] 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.

[[20210221130228]] 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 :

[[20200704153246]] 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

[[20210115090700]] 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.

[[20200710204125]] 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 [[20200710204125]].

[[20200705112816]] 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 [[20200909183033]]) 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 ;

[[20200909183033]] 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.

[[20200714155845]] 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.

[[20200707175829]] 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

[[20200707085937]] édition numérique

Le code source [[20200906135907]] 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é [[20210218193747]]. 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é [[20210313105330]].

Pour réunir ces deux matériaux en un espace de travail, les développeurs utilisent des outils programmables [[20210303174716]]. La programmation lettrée [[20200914211839]] 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 [[20210417145938]], 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 [[20210314114007]] (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).

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 [[20210405160832]] 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 [[20201224140951]]. 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.

[[20200509195652]] 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 [[20200718172257]]. 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 [[20210405121526]]) 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 [[20210412165919]] : 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].

[[20210116135423]] inscription computationnelle [[20200905210104]] 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 [[20201224140951]] 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]

[[20210430223919]] performativité du code

Le code n’est la source d’aucune action avant d’avoir été compilé [[20200907090751]] (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 [[20210502094415]] 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 [[20200704135046]] 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 [[20210813142419]]. 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 [[20210813142150]], de la reformulation de la solution

coloration syntaxique

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

[[20200930214400]] 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 [[20200522093949]], 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 [[20210520191108]] : 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 [[20200710204125]] sont ouverts et continus dans le sens où tout le monde peut intervenir dans le cycle de développement [[20210306102014]] (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 [[20210323194802]] 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 [[20210908111616]] 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 [[20210414220755]].

Des documents comme la convention de développement [[20210520193136]] 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) [[20210813142419]] 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

On distingue plusieurs strates 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 [[20210602103346]].
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. [[20200716211301]]
  • 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

Flore Barcellini[^1] 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 ;
    • coordination (synchronisation opératoire) : évolution et le maintien dynamique d’un contexte de connaissances, d’une représentation de la situation.

« 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)

On demande une double connaissance aux développeurs. À 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.

[^1]: Flore Barcellini, Conception de l’artefact, conception du collectif, 2018 [^2]: Jakob Nielsen, Usability Engineering, 1993

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

[[20210419170156]] complexité

La complexité d’un logiciel entrave le projet dans le sens où elle rend difficile la compréhension du logiciel. 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 [[20210813142419]]) dans le comportement du logiciel [[20210221130228]], 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 [[20210801123729]]. Chaque strate logicielle [[20200718172257]] 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 [[20200930183337]] 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 [[20210801123729]] 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 [[20210313113130]] le programme.

Décomposer en modules

Devant un système possédant de nombreux composants (issus de la structure du logiciel [[20210221144451]]) on se retrouvera devant un système compliqué, (voire hypercompliqué [[20210114195936]]). 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 [[20210313113130]] sont suffisamment stables (pas d’effet de bord [[20210109130837]] 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 [[20210908103929]] 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 [[20210421151432]] 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.

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

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é [[20210313105330]].

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 [[20200930183337]]). 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 [[20200704100343]].

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, [[20200508111132]], 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) [[20200701221037]] 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é.

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é [[20210425141727]]

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 [[20200724173541]] 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 la première documentation. Elle devrait être établie avant de commencer tout projet étant donné son impact sur tous les autres documents de la documentation logicielle [[20210118161126]]. Elle est également visée lors des revues de code [[20210109140006]] pour être appliquée, rappelée aux membres de l’équipe.

Dans la même logique des paradigmes de programmation [[20200530191442]], 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 [[20201224152456]] 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 [[20210520191108]].
  • Définir les règles d’écriture du code et des paradigmes [[20200530191442]] en application.
  • Présentation de l’architecture du projet, entre les fichiers (nom de fichiers, extensions…) et en leur sein (encodage [[20200717141735]]).

Il existe de nombreux guides énumérant des règles syntaxiques [[20200930214400]] 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.

[[20200815163702]] 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 [[20200606201922]] 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.

[[20200815162225]] interfaces d’écriture

Parsing

Dans les pratiques de l’écriture numérique [[20200606201922]], 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 [[20200930214400]], 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]

[[20200623180525]] 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 [[20210416144157]]. Pour cela on admet 16 critères.

Si l’architecture logicielle [[20210531145255]] 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.

[[20210109130329]] 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 [[20210207120845]] 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 [[20200704160828]], 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 [[20200907090751]] en CSS et permettent d’optimiser son inscription (avec la convention BEM [[20200715212459]]). 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 [[20210304181626]].

Chaque étape de ce cycle vient enrichir la documentation du logiciel [[20210118161126]] avec la description des expériences vécues et les décisions prises.

Il existe plusieurs diagrammes [[20210117165423]] 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 [[20210813142419]] : é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 [[20201224152456]] ;
  3. conception détaillée : architecture du logiciel ;
  4. programmation : implémentation, traduction des algorithmes dans un langage de programmation ;
  5. tests unitaires : test des modules [[20210421151432]] du logiciel ;
  6. intégration : interfacer les modules [[20210421151432]] 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.

[[20210313113130]] modularité logicielle

« 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 (artefacts 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

Elles permettent d’imaginer 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 [[20200505212332]].

Extreme Programming

L’Extreme Programming 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. Les sprints sont rapides avec un échange très régulier entre le commendataire et les développeurs. On insiste sur les principes suivants :

  • assurer la qualité du code avec le pair programming et la revue de code [[20210109140006]] 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 [[20210109130329]] ;
  • besoin d’un retour régulier et assuré sur les fonctionnalités avec le développement piloté par test [[20210525213204]] et l’intégration systématique de fonctionnalités stables.

On 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. Une application simple et soignée pourra de toute manière évoluer avec fluidité.

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 [[20210118161126]] 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 [[20210313105330]] pour être introduits en quelques exemples. Il faudrait d’abord que le développeur se familiarise avec les différents modules [[20210421151432]] à maîtriser, leur interfaçage.

Utilisation dictée par l’architecture

Ces programmes qu’il est difficile d’aborder sont peu abstraits [[20210412165919]]. 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 [[20200930183337]] 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 [[20210531145255]].

« 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 [[20210412165919]] 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 [[20210524081927]]) 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 [[20210701175229]] 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 [[20210520191108]] ne suffit pas à informer l’utilisateur de la portée hypertextuelle de l’environnement de développement [[20210130151200]] 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 [[20200914211839]]) 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 [[20201220084534]] ne permettent pas de faire de lien hypertexte. Il est nécessaire d’utiliser un EDI [[20210303170947]] pour obtenir une mise en forme des annotations (panneau contextuel au survol, interprétation du Markdown [[20210829171922]]…) 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 [[20201224152456]] (plateforme, langage de programmation utilisé, version utilisée…)
  • temporel (quels échanges de requêtes [[20210405160832]] 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 [[20210117100240]] 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 [[20210427194405]].

Le code source est filtré par une vue [[20200708121357]]. 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

[[20210313113130]] 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 [[20210417145938]] vont permettre d'ajouter des fonctionnalités tandis que les frameworks permettent de mettre en place une architecture pour les différents processus.

[[20200701222949]] 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 [[20210109130329]] 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.).

[[20200709214912]] 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.

[[20200701221037]] 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.

[[20200710204125]] 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 [[20210304181626]] 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 [[20210109140006]] 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 [[20210118144930]], 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 [[20210109140006]] 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

[[20210801123729]] 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 [[20210421151432]]) évitant ainsi la régression, la perte du support de certaines fonctionnalités dû à des effets de bord [[20210109130837]] 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 [[20210109140006]] le code pour qu’il soit simple et clair.

C’est une approche didactique que l’on retrouve dans la programmation lettrée [[20200914211839]]. 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

[[20200912130028]] visualisation

Un diagramme est une vue simplifiée [[20200708121357]] 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 » [[20200625115033]] :

  • 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é [[20210419170156]] 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 [[20210702114815]] 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

[[20200705100544]] 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]

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]

Selon Dominique Cardon, cela tient à trois facteurs :

  • 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[^2] entre internautes, mais à calculer une valeur qui les singularise et les distingue les uns des autres »[^1]

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

[[20200509195652]] 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 » 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]

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 » (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 »[^3]

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 »[^3]

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 « privatiser la privacy »[^3].

« 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. »[^3]

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 »[^3]

[^1]: Dominique Cardon, Internet par gros temps, 2015 [^2]: voir [[20200705112816]] production de contenu web [^3]: Antonio Casili, Qu’est ce que le digital Labor : Travail, technologies et conflictualités, 2015 [^4]: voir [[20200625095558]] é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.

[[20200508093223]] 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

[[20210405121526]] discret / continu

Plus un modèle [[20200526222401]] est granuleux (composé de nombreux éléments), discrétisé, plus les combinaisons [[20210416144157]] (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 [[20210419170156]], 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 [[20210118161126]]. 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 [[20210218203301]] 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 [[20201224152456]].

Les principaux langages permettant d’inscrire de la documentation sont

  • Markdown [[20210829171922]]
  • 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 [[20210221144451]]. De là, ils sont compilés [[20200907090751]] en site statique [[20210218203301]] 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 [[20200508111132]] 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 [[20210524081927]] ne se prête pas à une démonstration du code source [[20210906111350]], 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]

[[20200724153738]] 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

[[20200708172120]] 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 [[20200606201922]].

C’est ainsi qu’il devient possible de créer des protodocuments[^2] dans le processus documentaire [[20200724153738]], 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 [[20200722215106]].

[^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

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é [[20210425141727]] 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 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 [[20210213103719]] ; 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 [[20210701175229]], 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