Messages et protection

novembre 30th, 2017

Une protection des messages basés les objets et liens de nebule peut être mise en place. Cette protection ne vise pas à dissimiler la présence d’un message mais à dissimuler son contenu. La dissimulation de la présence d’un message, plutôt nommée offuscation, est un autre sujet à part entière.

Mais cette protection peut ne pas être efficiente et elle peut se retrouver mise à mal du fait du fonctionnement même des liens de chiffrement (type k). Le lien de chiffrement va associer l’empreinte du message en clair avec l’empreinte du message chiffré. Hors un message de petite taille va avoir une forte probabilité avec le temps d’être (re-)créé par ailleurs et donc de dévoiler le contenu d’un message protégé. Et même pour un message plus conséquent, si il est partiellement ou complètement redécoupé en sous-objets via des liens de subdivision (type s), peut voir une partie de son contenu protégé dévoilé. La subdivision peut être par ailleurs légitime dans le cas d’un pré-découpage par mots pour la recherche sur mots clés.
La protection doit donc être adaptée dans le cas de la messagerie.

L’ajout d’un sel avant chiffrement ne résout pas le problème puisqu’il ne masque pas le lien entre le texte clair et chiffré. Par contre il est peut-être possible de pré-saler l’objet à chiffre et ne le reconnaître que sur son empreinte pré-salée.
A travailler…

Modification du thème du bootstrap

octobre 22nd, 2017

Le thème graphique du bootstrap se transforme un peu pour mieux coller à la nouvelle vision développée dans la Réflexion sur l’évolution de l’interface web pour nebule.

L’application 0 voit maintenant ses icônes centrées dans la page et a une icône dédiée au bootstrap/break.

020171022-shot-2017-10-22_18-13-55

Réflexion sur l’évolution de l’interface web pour nebule – dans klicty

octobre 22nd, 2017

Suite des articles Réflexion sur l’évolution de l’interface web pour nebule, objets, entités et entités 2.

Voici l’évolution en cours de l’interface de klicty.

La vue des entités pour se connecter :

020171022-shot-2017-10-22_18-15-25 Read the rest of this entry »

Réflexion sur l’évolution de l’interface web pour nebule – entités 2

septembre 7th, 2017

Suite de la réflexion sur l’évolution de l’interface web pour nebule, objets. et entité.

Il y a deux façons d’afficher des objets.

La première ressemble à ce qu’il y avait avant, mais en plus complet. Les boutons d’action sont affichés sous la barre de titre de l’objet :

20170907-shot-2017-09-07_22-19-28

Read the rest of this entry »

Réflexion sur l’évolution de l’interface web pour nebule – entités

septembre 2nd, 2017

Suite de la réflexion sur l’évolution de l’interface web pour nebule et objets.

Le code de génération graphique de l’affichage des objets progresse. La mise en place d’une fonction getDisplayList() permet de gérer beaucoup plus facilement une liste d’objets.

Voici un comparatif d’une liste d’entité avec l’ancienne méthode et la nouvelle :

 20170902-shot-2017-09-02_18-35-52

Et :

20170902-shot-2017-09-02_19-09-22

Pondération et structure hiérarchique

août 30th, 2017

Suite de la gestion de la pondération.

Dans une structure ou une organisation hiérarchique, forme courante d’organisation, une autorité peut être amenée à déléguer son pouvoir à un autre individu. C’est le cas notamment leur d’une vacance.

Rapporté à une entité dans nebule, une entité a qui on donne une forte pondération, à qui on fait confiance, sera toujours prioritaire sur une autre de moins forte pondération. Comment permettre une vacance ? Est-ce que l’on peut mettre en place une forme de délégation de pondération ? Est-ce que ce lien de délégation est simplement annulé en fin de vacation ?

Cela pose aussi question sur la forme de la pondération. Elle est normalement globale. Mais ne faut-il pas gérer une pondération par rôle en plus ? Doit-il être géré comme une pondération avec un contexte social ?

Réflexion sur l’évolution de l’interface web pour nebule – objets

août 29th, 2017

Suite de la réflexion sur l’évolution de l’interface web pour nebule.

Au moyen d’une nouvelle fonction d’affichage dans la bibliothèque nebule, la fonction getDisplayObject(), il est maintenant possible de déléguer plus facilement l’affichage d’une liste d’objets ou d’entités.

Voici l’affichage inséré dans un textes :

20170829-inline

Les différents formats d’affichage en blocs avec une hauteur de 32px, 64px, 128px puis 256px :

20170829-bloc-1

20170829-bloc-2


20170829-bloc-3


20170829-bloc-4

Plusieurs blocs s’assemblent pour remplir toute la largeur disponible en rapport avec leur largeur propre. Les informations internes affichées des blocs sont complètement indépendantes les unes des autre. Cela donne :

20170829-assemblage-bloc

La fonction permet aussi un affichage en liste avec un objet par ligne :

20170829-lignes

Quelques possibilités :

  • Le carré de l’icône peut être remplacé par une image ou masqué.
  • Le carré de la couleur n’est pas modifiable est dépend uniquement de l’ID de l’objet, mais peut être masqué.
  • Le nom de l’objet peut être remplacé par un texte.
  • L’identifiant de l’objet peut être masqué.
  • Les entités ou objets de référence (au dessus du nom) peuvent être masqués et si la liste est trop longue il se réduisent aux carrés de couleur et d’icône, voir juste au carré de couleur.
  • Les icônes de protection, de dissimulation et de verrouillage sont activables (en fond vert) et peuvent être masqués.
  • Les émotions sont calculés automatiquement et peuvent être masquées.
  • Le compteur est personnalisable et peut être masqué.
  • Certains éléments ne peuvent pas être affichés ensemble, surtout quand la place est limitée.
  • Les blocs sont centrés par défaut, leurs assemblages aussi.

Il reste à faire la deuxième partie de ces affichages d’objets, c’est à dire de les rendre utilisables autrement que juste par des liens hypertextes. L’idée est de rendre les carrés de l’icône et de la couleur sensible au clic pour afficher un menu complet des actions sur l’objet. Les actions seront dépendantes des modules via la mise en place de nouveaux points d’accrochage (hooks).

Réflexion sur l’évolution de l’interface web pour nebule

juillet 27th, 2017

Au fil du temps l’interface graphique, communément appelée Interface Homme-Machine (IHM), implémentée dans les dérivés de nebule s’améliore et se structure autour de la bibliothèque commune. Cette bibliothèque incorpore de mieux en mieux la préparation de plus en plus d’éléments graphiques communs.

Cependant elle reste insatisfaisante.

Il n’est pas question de parler d’un interface d’application qui apporterait quelques solutions à certains problèmes mais entraînerait de fait bien des problèmes d’interopérabilité et le suivi des codes qui vont avec.

L’interface web semble la plus adaptée aujourd’hui mais traîne malgré sa bonne standardisation la question de la gestion des multiples supports d’affichages. La philosophie habituelle à la mode consiste à faire gérer par même page l’ensemble des affichages possibles dans tout le gradient entre les plus minuscules smartphones et les ordinateurs aux écrans très haute résolution. Sans parler du très faible écart en résolution des écrans à mettre en parallèle à leur l’écart de tailles.

C’est sans compter aussi le questionnement sur l’usage invasif et disproportionné du JavaScript (JS). De plus en plus de pages web sur Internet incorporent des parties de code/JS/images/etc venant de différents CDN. L’éclatement du moteur de la page en de multiples dépendances est tenable avec l’Internet actuel mais est profondément en opposition au fonctionnement de nebule et est par nature très sensible à la fragmentation possible de l’Internet dans le futur. Le JS trop pointu est clairement une source de dysfonctionnement ainsi qu’une source de problèmes de sécurité.

L’interface comporte deux parties:

  1. le contenu de la page contenant l’information principale attendue par l’utilisateur ;
  2. le cadre de la page avec des informations liées à l’environnement de l’information affichée ou à l’application.

Ces deux parties doivent être plus clairement décorrélées graphiquement. L’idée est d’essayer de rendre plus léger, aérien, le contenu et plus discret le cadre.

La vision d’avenir, sauf catastrophe, ce sont d’un côté des écrans toujours plus grands avec des résolutions toujours plus fines. Quand on dit grand c’est vraiment grand, au point que de vouloir mettre en plein écran une application n’ai plus vraiment de sens. Et d’un autre côté une scission des appareils nomades en de multiples composants plus ou moins autonomes parmi lesquels l’écran sera détaché au plus près des yeux de l’utilisateur, là encore avec des résolutions très fortes et avec de la transparence (canal alpha). Il faut aussi voir disparaître le clavier et la souris au profit du tactile, de la commande vocale et du pilotage par les yeux et même via une interface avec le cerveau. Il faut penser dès maintenant à préparer l’affichage des pages pour qu’il y ai une continuité entre la page web affichée aujourd’hui et celle affichée avec les évolutions prévisibles de demain.

La présence quasi systématique du double carré d’un objet peut permettre de le rendre actif en y cachant un menu des actions possibles simplement en cliquant dessus. Ainsi une liste d’objet ne sera plus polluée par de multiples boutons dans le cadre et sous chaque objets. Le menu lié à l’objet est bien sûr contextuel dans l’application et dépendant du type d’objet. Dans la page qui affiche les entités, cliquer sur une entité fera afficher le menu lui correspondant dans lequel on trouvera le bouton qui permet de se connecter avec cette entité.

Dans les menus du cadre ou des objets, l’activation d’un bouton ne sera plus immédiatement suivi d’une action, et d’un rechargement de page, mais fera apparaître des informations plus précises sur l’action du bouton et demandera un déplacement explicite sur un nouveau bouton pour valider l’action. Ainsi ce fonctionnement n’est pas trop pénalisant pour un usage à la souris et est très adapté à l’usage mobile tactile sur de petits écrans.

Les messages qui s’affichent en début de contenu, typiquement des alertes, seront systématiquement affichés à chaque rechargement d’une page mais devront pourvoir être cachés pour mieux accéder au contenu.

L’affichage du contenu doit être centré par défaut horizontalement et verticalement. Sur un écran de petite résolution on doit limiter l’affichage pour avoir juste ascenseur vertical. Sur un écran de haute résolution le cadre sera suffisamment loin pour que tout ce que l’on fait sur l’objet en cours d’affichage soit clairement une action sur l’objet. On peut à l’avenir imaginer que l’espace du contenu dispose de plusieurs zones qui affichent des objets différents simultanément, et donc potentiellement dans des contextes différents.

Le cadre doit contenir les informations sur l’entité connectée et le contenu doit faire référence au besoin à la vue restreinte à une entité si ce n’est pas l’entité connectée.

Réorganisation des entités spéciales – inventaire de départ

juin 25th, 2017

L’organisation actuelle des entités spéciales est assez limitée. On a d’un côté les autorités globales imposées par le code et de l’autre quelques autorités locales aux rôles limités.

Le bestiaire

Premier constat fait depuis un moment, l’entité maître unique puppetmaster est par définition un risque même si pour l’instant c’est la seule façon raisonnable d’avoir une cohérence de l’ensemble. Le but serait d’avoir une entité multi-tête à seuil dont le contrôle est réparti entre plusieurs porteurs. Cette entité n’a que pour mission de désigner les autres entités spéciales globales dont la plus utilisée aujourd’hui est l’entité maître du code bachue. L’entité puppetmaster a un rôle d’autorité et sa portée est globale.

L’entité spéciale cerberus permet de gérer les bannissement d’objets. C’est un peu le rôle de police. L’enfer n’ayant pas encore officiellement ouvert, cette entité n’est pas utilisée mais elle pourrait être très rapidement sollicitée fortement pour tout et n’importe quoi.

L’entité spéciale maître du code bachue est aussi désignée autorité mais est subordonnée au puppetmaster. Son rôle est uniquement de gérer le code sous toutes ses formes.

L’entité spéciale kronos n’a qu’un rôle théorique pour l’instant et n’a que brièvement été utilisée dans des expériences. Cette entité va générer des repères temporels fiables. Mais je pressens qu’elle va devenir incontournable à l’avenir, et peut-être critique pour certains usages.

Enfin, l’entité spéciale asabiyya va être utilisée pour relier les gens avec de la confiance. Elle n’est pas encore utilisée non plus.

Les rôles

On peut distinguer plusieurs catégories d’entités. Les autorités désignes des entités sur des rôles. Les administrateurs font des choix de configuration du code et des applications. Les gestionnaires gèrent des objets, des applications, des entités. Et chaque rôle peut avoir une portée locale ou exceptionnellement globale.

Il existe déjà des méthodes d’organisation qui avaient été retranscrites dans l’article Être relié ou ne pas être. Le modèle RBAC est implémentable par les liens de nebule, le modèle OrBAC semble être moins adapté à nebule parce qu’il sous-entend une une organisation, une structure, qui n’est pas portée par nebule.

La liste de grandes catégories de rôles à compléter peut déjà prévoir l’autorité (authority), la police, l’administrateur (administrator), le gestionnaire (manager), l’entité de recouvrement (recovery)…

L’attribution de rôle est additive, les rôles s’ajoutent à une entité mais il n’y a pas de négation de rôle. Pour les rôles locaux, il est possible de supprimer un rôle d’une entité. Il n’y a pas d’inhibiteur de rôle mais juste un une suppression de lien.

La réflexion continue…

Modification des sources d’aléa – implémentation

juin 8th, 2017

Suite à l’article Modification des sources d’aléa, la fonction getPseudoRandom a été modifiée dans la bibliothèque PHP orienté objet de nebule pour ne plus consommer du tout de ressource d’aléa mais en gardant une entropie forte.

La génération se fait depuis une graine qui est la concaténation de la date, de l’heure en micro-secondes, du nom de la bibliothèque, de la version de la bibliothèque et enfin de l’identifiant de l’instance locale du serveur. La graine dépendant donc surtout de l’heure avec une grande précision et est spécifique à chaque serveur.

La graine sert à générer via une fonction de hash l’état du compteur interne. Comme la taille du hash est fixe, une boucle permet d’alimenter la sortie en dérivant successivement l’état du compteur interne. À chaque tour de la boucle, l’état du compteur interne est dérivé en calculant le hash de lui-même. À chaque tour de la boucle, on concatène à la sortie le hash de l’état du compteur interne concaténé à une valeur fixe. L’état du compteur interne n’est jamais directement sorti et il est effacé en fin de génération de fonction.

Le bootstrap utilise aussi une génération pseudo aléatoire pour la création notamment d’identifiants temporaires. La bibliothèque PHP procédurale intégrée au bootstrap a aussi été modifiée. Elle fonctionne sur le même principe décrit ci-dessus. Une nouvelle fonction __pr est créée et les fonctions ne nécessitant par un aléa fiable ont été modifiées.

La fonction de hash actuellement utilisée pour la dérivation du compteur interne et la fonction sha256. Comme on attend pas de propriété cryptographique forte dans cette fonction, n’importe quelle fonction de hash peut faire l’affaire.

Ce sera disponible dans la prochaine version diffusée de la bibliothèque de nebule.

Échange ou téléchargement d’objet et lien de mise à jour

juin 6th, 2017

Dans l’article Échange ou téléchargement d’objet, on a vu qu’il y avait deux façons de récupérer le contenu d’un objet. Il y a une deuxième différence qui peut apparaître dans certains cas, c’est la transmission du contenu d’origine ou de celui d’un autre objet si il a été créé un lien de mise à jour de l’objet demandé.

  1. Via un lien web avec comme argument /o/id on télécharge le contenu de l’objet avec comme nom son identifiant id. Les liens de mise à jour ne sont pas utilisés parce que l’empreinte de l’objet est vérifié après téléchargement et que si le serveur envoie un autre objet, fut-il une mise à jour, l’objet sera rejeté.
  2. Via un lien web avec comme argument ?o=id on télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. Mais dans ce cas les liens de mise à jour sont exploités et le contenu renvoyé par le serveur peut ne pas avoir l’empreinte de l’objet demandé.

La prise en compte des liens de mise à jour est toujours délicate parce que cela peut permettre de substituer un objet par un autre. Cette manœuvre est complètement visible dans les liens et nécessite un bon échantillonnage des liens par rapport à leurs poids sociaux.

Modification des sources d’aléa

juin 3rd, 2017

La bibliothèque nebule en PHP orienté objet présente deux fonctions de génération d’aléa dans la classe dédiée à la cryptographie.

Les fonctions :

  • public function getPseudoRandom($size=32)
  • public function getStrongRandom($size=32)

La première fonction getPseudoRandom permet de générer un aléa correct mais pas fiable, c’est à dire de qualité mais pas pour un usage cryptographique sûr. Il va servir principalement pour générer des identifiants d’objets de références.

La seconde fonction getStrongRandom permet de générer un aléa beaucoup plus fiable, c’est à dire réellement non prédictible, pour un usage cryptographique sûr. Cependant cet aléa est précieux parce que sa génération prendre du temps et peut consommer des ressources, ce qui limite la quantité de bon aléa que l’on peut demander à un instant donné. Il doit donc être réservé strictement à des usages requérant un aléa fiable.

Or, la fonction getPseudoRandom fait appel à la même fonction interne openssl_random_pseudo_bytes que getStrongRandom, ce qui veut dire qu’elle consomme de l’aléa précieux alors que ce n’est pas nécessaire.

Cette fonction getPseudoRandom va être modifiée pour générer un aléa correct mais non fiable à partir de la date/heure et une préparation via une ou plusieurs fonctions de hachage. Elle ne devra en aucun cas être utilisée comme source pour générer des mots de passes de session ou de protection des objets, etc… nécessitant un aléa de qualité cryptographique.

Bugg d’affichage des autorités globales dans option

juin 2nd, 2017

Il y a un petit problème dans l’affichage des autorités globales dans l’application option. Par exemple ici :

https://sylabe.com/?a=21215100000000…0000000212151&view=gauth
shot-2017-06-02_19-51-13

Mais une partie de l’affichage est bon est correspond bien à l’entité bachue qui gère le code. Un petit tour par le bootstrap permet de s’en assurer :

https://sylabe.com/?b
shot-2017-06-02_19-57-13

bootstrap – Mise en ligne

juin 1st, 2017

Une nouvelle 020170508 version du bootstrap est mise en ligne.

Le développement continue sur l’application option avec sa séparation de la gestion des autorités globales et locales.

La réflexion est toujours en cours sur l’avenir des autorités globales mais les autorités locales vont sûrement être scindées en plusieurs rôles sous des dénominations différentes.

Pas d’installateur complet pour cette fois, les deux applications sylabe et klicty sont mise à jour.

Le code est disponible ici :

94373583d31df5241fdf19de50be0e65fb6f65387188866818aebadd5a7217c5

PFS sans connexion

mai 22nd, 2017

La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.

Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.

La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).

La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.

De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.

Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…

Entité multi-rôles – suite

mai 22nd, 2017

Suite de l’article sur les Entité multi-rôles.

La gestion de multiples clés cryptographiques asymétriques dépendantes d’une seule clé principale impose des contraintes lors de la synchronisation d’entité mais il n’est pas difficile à mettre en place.

La première idée serait de protéger les mots de passe des clés secondaires avec la clé primaire. Mais cette clé primaire a avant tout le rôle d’authentification, elle ne doit donc pas servir à faire du chiffrement.

La seconde idée consiste à dériver (PBKDF) les mots de passe des clé secondaires du mot de passe de déverrouillage de la clé primaire. Ainsi la clé primaire ne sert qu’à l’authentification. Cela implique aussi que la modification du mot de passe de la clé primaire force le changement de mot de passe de toutes les clés secondaires associées.

La dérivation des mots de passe peut prendre en compte la partie publique de la clé primaire et de la clé secondaire concernée. Elle peut aussi prendre en compte, en plus, l’ID dans nebule du rôle associé. Une implémentation complète devra être proposée.

Entité multi-rôles

avril 20th, 2017

D’un point de vue robustesse et sécurisation des clés cryptographiques, il est recommandé de séparer les rôles des différentes clés utilisées. Une clé crypto ne doit avoir qu’un seul usage, c’est à dire un seul rôle. Dans l’implémentation des entités dans nebule, les entités étant des clés cryptographiques avec de multiples rôles, il va falloir les scinder.

Les rôles les plus fréquents sont :

  1. L’authentification. C’est utilisé pour le déverrouillage des entités.
  2. La signature. Tous les liens sont signés.
  3. Le chiffrement. Il intervient dans la protection des objets et la dissimulation des liens.

Toutes les clés liées à des rôles peuvent être rattachées à une clé cryptographique asymétrique principale et reliées à celle-ci par des liens. Il est possible par la suite d’étendre sans problème les rôles comme par exemple les rôles d’autorités locales.

La segmentation des clés par rôles impose la gestion de multiples clés pour une entité, notamment lors de la synchronisation sur différents supports. Mais elle permet en cas de compromission d’une clé de limiter l’étendu des dégâts.

Modification de l’ordre de prise en compte des propriétés d’un objet

mars 30th, 2017

Je reprends progressivement le développement de nebule pour corriger le bugg de klicty et améliorer dans sylabe le module correspondant.
Et je tombe sur un problème non dans l’implémentation mais dans la façon dont on prend en compte les propriétés d’un objet, ou plutôt l’ordre de prise en compte lorsque cela est fait plusieurs fois. C’est à dire, quel propriété retient-on en priorité lorsqu’il y a plusieurs liens d’un objet vers plusieurs propriétés.
Le problème n’a pas une solution difficile en soi mais le fait qu’il concerne une brique importante de nebule me freine à le modifier sans plus de réflexion. Les implications que cela engendre peuvent être très importantes dans pleins d’endroits du code de la bibliothèque de nebule et des applications. Read the rest of this entry »

Échange ou téléchargement d’objet

mars 28th, 2017

Un objet peut être récupéré de deux façons.

  1. Via un lien web avec comme argument /o/id on télécharge le contenu de l’objet avec comme nom son identifiant id. L’empreinte est ensuite vérifié pour voir si elle correspond à l’identifiant.
  2. Via un lien web avec comme argument ?o=id on télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. cela permet de télécharger l’objet sous une forme de fichier classique. On fait ainsi une dé-nébulisation de l’objet. C’est aussi le seul moyen d’avoir accès au contenu protégé hors nebule.

Mais pour un utilisateur, ces deux méthodes ne se valent pas. La première méthode sert à la synchronisation et l’échange d’objets entre programmes et n’a pas pas d’intérêt direct pour l’utilisateur. La seconde lui permet au contraire de reprendre un objet sous une forme classique de fichier.

Actuellement un problème existe dans klicty puisque un objet non protégé peut être téléchargé, c’est le but de l’application, mais c’est fait avec la mauvaise méthode. Donc le fichier téléchargé n’a pas le bon nom. Alors que pour un objet protégé ce problème n’existe pas puisqu’il faut impérativement passer par la deuxième méthode pour avoir accès au contenu non protégé.

La première méthode doit être exclusivement réservée à la synchronisation d’objets.

CF : bootstrap – Arguments en ligne et accès directs

Correction dans l’affichage

février 16th, 2017

Une nouvelle version de la bibliothèque a été générée pour corriger un petit problème dans l’affichage des objets.

Cette version sera préparée et mis en ligne plus tard…

Elle est pour l’instant utilisée sur des tests de développement de programmes.