gouttegd a écrit 1805 commentaires

Je dis justement que je peux aussi faire l'analyse sans qu'on m'ai préparé un compte rendu.

Analyse basée sur l’hypothèse que l’historique qu’on t’a transmis contient tout ce que tu as besoin de savoir. J’espère pour que pour toi que c’est bien le cas. (Voir mon message plus bas sur les discussions en plusieurs threads, et l’absence totale de garantie que le thread qu’on te passe contient bien toute la discussion.)

Et tu as omis mon dernier paragraphe qui dis que chaque organisation voit comment elle se gère et que c'est à voir qui doit faire l'analyse celui qui transmet ou celui qui reçoit. Dans mon expérience c'est plus efficace que ce soit le second.

Putain, c’est magique…

La discussion commence par quelqu’un qui raconte son expérience :

Mon expérience (et pas qu'une fois) : le mail qui contient juste "peux-tu regarder ?" suivi de 30 pages de mails, avec l'information pertinente perdue au milieu des signatures, des entêtes, des suivis, et j'en passe.

Tu répliques par une affirmation péremptoire :

Ce genre de mail consiste justement à extraire et détailler l'information utile.

Je fais remarquer que non, ce n’est pas une généralité :

Bah non, pas forcément, je ne vois pas ce qui te fait dire ça. Ce qu’on te demande quand on t’envoie ce genre de mails n’est pas forcément une information contenue dans l’historique de la discussion.

Nouvelle réponse péremptoire :

C'est exactement pareil.

Et nouvelle généralité (à peine tempérée par un modeste « quasiment ») :

La personne qui va faire passe et quasiment systématiquement moins compétente sur le sujet

(OK, à partir de là je généralise aussi en postulant que quelqu’un d’assez compétent pour participer à une discussion est aussi compétent pour en extraire un résumé compréhensible. Je plaide coupable. Je veux bien admettre que ce n’est pas forcément toujours le cas — mais ça le devrait¹).

Et à la fin tu conclus que non, mais chaque organisation fait comme elle l’entend, hein, moi je ne faisais que partager mon expérience qui dit que ma façon de faire est la bonne, c’est tout.

Merci pour la rigolade, mais j’ai assez perdu de temps, j’ai des compte-rendus à rédiger.

---

¹ Je soupçonne au passage que si la personne est incapable de faire une synthèse correcte, ce soit beaucoup plus parce que ça la gonfle de devoir faire une synthèse, que parce qu’elle n’en a pas les compétences. Mais je généralise, désolé.

Je déteste les compte-rendus.

Et alors ? Je ne connais personne qui aime ça. Ça n’enlève rien au fait qu’il y a des situations où un bon compte-rendu est utile.

Il y a plein de choses dans le même genre. La documentation, les tests unitaires… je ne connais personne qui aime ça. C’est chiant à faire, c’est jamais complet, pendant qu’on fait ça on n’avance pas sur ce qui est important, etc.

Je comprends très bien qu’on veuille s’épanouir dans son travail en passant plus de temps sur les choses qu’on aime faire, mais perso je souhaite ne jamais avoir à travailler avec des types qui poussent ça jusqu’à refuser de consacrer la moindre seconde de leur temps aux tâches qu’ils n’aiment pas — et pire encore, qui tentent de justifier ça en disant « ça sert à rien d’toute façon, j’suis un dev moi, pas un gratte-papier qui ne produit rien ! »

Sinon pour avoir un OID d'entreprise, c'est gratuit, ça se fait auprès de l'IANA par exemple, mais tout le monde ne peut pas en avoir un

Je ne sais pas si les conditions d’obtention ont changé depuis, mais j’en avais obtenu un il y a une quinzaine d’années. On ne m’a opposé aucune difficulté, juste une ou deux questions sur ce que je comptais en faire. L’OID m’a été attribué en trois jours.

On peut aussi mentionner l'outil shelldap

À l’époque où je faisais du LDAP (il y a une quinzaine d’années donc), j’aimais bien aussi ldapvi, pour modifier des entrées LDAP au format LDIF depuis un éditeur comme Vim.

Je ne sais pas s’il est toujours utilisable, la dernière mise à jour date de 2010… Il compile toujours en tout cas (modulo une fonction à renommer), mais ça fait longtemps que je n’ai plus de base LDAP contre lequel le tester !

Parfois c’est encore pire, la partie utile n’est même pas dans l’historique joint au message.

Pour peu que la discussion ait duré suffisamment longtemps ou ait impliqué un grand nombre d’intervenants, elle risque fort d’être éclatée en plusieurs threads, et rien ne garantit que la partie utile sera dans le thread dont l’historique a été passé au nouvel intervenant.

Raison de plus pour faire une synthèse de la discussion, qui d’ailleurs ne bénéficiera pas seulement à la personne dont on sollicite l’avis mais aussi à tous les autres participants à la discussion.

Le demandeur n'est probablement pas à même de déterminer ce qui est l'information pertinente ou non pour que tu donne ton avis.

Not buying it, sorry. Il participe à une discussion s’étalant sur plusieurs dizaines de messages et il n’est même pas fichu de faire un résumé du problème ? Peut-être qu’il n’avait rien à faire dans la discussion en premier lieu, alors.

La personne qui va faire passe et quasiment systématiquement moins compétente sur le sujet.

Encore une fois, not buying it. S’il était assez compétent pour participer à la discussion jusqu’au moment où il se rend compte qu’une personne mieux placée pour résoudre le problème n’est pas là, il devrait être assez compétent pour exposer le problème en question.

alors c'est par manque de temps qu'elle ne répond pas elle même au mail donc lui demander de prendre du temps en plus ne marche pas bien.

Voilà. Je veux bien accepter l’excuse du manque de temps, mais par contre essayer de faire passer ça pour de l’humilité en mode « mes compétences si inférieures aux vôtres ne ne permettent pas de vous faire un résumé, aussi je vous transmets l‘intégralité des trois dernières semaines de discussion », c’est du foutage de gueule, désolé. En réalité, le message c’est « mon temps est plus précieux que le tien, débrouille-toi avec ça. »

Ce genre de mail consiste justement à extraire et détailler l'information utile.

Bah non, pas forcément, je ne vois pas ce qui te fait dire ça.

Ce qu’on te demande quand on t’envoie ce genre de mails n’est pas forcément une information contenue dans l’historique de la discussion. On peut te demander ton avis sur une idée qui a été proposée dans la discussion, on peut te demander de rajouter des infos inconnues des participants, etc.

Et comme dit PsychoFox plus bas, si après une discussion qui s’est potentiellement étalée sur plusieurs semaines (voire mois) et a consisté en plusieurs dizaines de messages, on décide de solliciter une personne extérieure à la discussion pour son avis/aide/commentaire pertinent/etc, la moindre des choses c’est de synthétiser la discussion et de poser une question précise, au lieu de laisser le destinataire fouiller l’historique à la recherche de la question.

D’autant plus que dans une discussion suffisamment longue, il est tout-à-fait possible qu’il y ait eu plusieurs questions abordées, ce n’est pas forcément évident pour le destinataire de savoir sur quoi on lui demande son avis si tout ce qu’il a, c’est un message comme ça :

Dis, je me souviens que tu as passé pas mal de temps à bosser sur X à une époque, qu’est-ce que tu penses de ça ? T’as une meilleure idée à proposer ?

----- Original message -----
bla bla
----- Original message -----
bla bla
----- Original message -----
etc.

Quand bien même on n’en aurait rien à faire de la politesse, c’est aussi une question d’efficacité.

(Et même dans le cas où on demande une synthèse, ça n’interdit pas de le demander clairement : « Tu peux me faire une synthèse de cette discussion pour la réunion de demain ? », au lieu encore une fois de laisser le destinataire deviner ce qu’on attend de lui.)

Si des gens me prennent pour le chieur de service parce que j’ai l’outrecuidance de les obliger à baisser le regard de quelque degrés pour trouver un lien à la fin du mail, ben ils me prennent probablement pour le chieur de service pour plein d’autres raisons. Donc → rien à foutre.

Si j'envoie un lien vers mes chaussettes bleues, c'est mieux, non ?

Moi je préfère l’option du lien en note [1]. C’est une convention que tout le monde semble comprendre, et qui ne nécessite pas d’HTML.

Certes, ça pose des problèmes de sécurité car Mme MICHU ne va pas vérifier que le second lien pointe vers un truc qu'elle connaît et auquel elle peut faire confiance.

Faux problème. Pour la plupart des utilisateurs, rendre le lien apparent ne les rendra pas moins susceptibles de cliquer dessus, peu importe à quoi ressemble le lien.

Si une utilisatrice est du genre à savoir ce qu’il faut regarder dans un lien pour repérer les trucs louches, elle sera probablement aussi du genre à laisser son pointeur au-dessus du lien quelques secondes le temps de voir l’URL s’afficher dans l’espace prévu à cet effet.

[1] https://sous-domaine.nom-de-site-a-la-con.com/service-debile/A6787FD89789787?option1=mon_slip&option_inconnue_mais_geniale=mes_chaussettes_bleues&skip=14

Pas grand’chose à voir. OpenPGP est très utilisé pour chiffrer/signer des « données au repos » (data at rest), potentiellement sur de longues durées. Ceux qui réclamaient le maintien du support pour de vieux algorithmes sont tous ceux qui voulaient conserver la possibilité de déchiffrer leurs vieilles archives de messagerie ou leurs vieilles sauvegardes datant des années 1990¹.

Des protocoles utilisés pour le chiffrement de données en transit, comme TLS ou WireGuard, n’ont nul besoin de supporter des algorithmes obsolètes.² C’était justement ça l’erreur de TLS : pas l’agilité cryptographique en soi, mais l’agilité cryptographique avec une liste de trouze mille algorithmes, dont certains complètement dépassés et, pire encore, certains délibérément affaiblis pour suivre les législations des années 1990 (les suites TLS_EXPORT) — et même, encore vraiment pire, des pseudo-algorithmes qui en réalité ne chiffrent pas du tout (les suites TLS_NULL).

Ajoute à ça que de toutes les implémentations d’OpenPGP, GnuPG est celle qui a à la marge de manœuvre la plus étroite quand il s’agit des vieux algos, parce que c’est la seule à les supporter — toutes les autres implémentations sont nées beaucoup plus tard et ont choisi de ne supporter d’emblée que les algos modernes ; elles pouvaient se le permettre précisément parce que GnuPG était là pourceux qui avaient besoin des vieux algos !

Bref, la difficulté de retirer un algo pour les développeurs de GnuPG n’indique pas grand’chose de la difficulté qu’il y aurait à retirer un algo dans WireGuard, si ce dernier avait fait le choix d’en supporter plusieurs.

Par ailleurs, les auteurs de WireGuard semblent confiant dans leur capacité à imposer à tout le monde de passer à un hypothétique WireGuard-v2 le jour où il faudra changer d’algo, donc pourquoi croire qu’ils ne seraient pas capable d’imposer le retrait d’un algo ?

(À moins bien sûr que cette capacité ne soit que du flanc, et qu’en réalité ils n’aient pas la moindre idée de la procédure qu’il faudra mettre en œuvre le jour où il faudra basculer…)

---

¹ Et qui auraient mieux fait de re-chiffrer leurs vieilles archives avec des algos plus modernes plutôt que de les conserver chiffrées avec les vieux algos de l’époque, mais bon…

² Sauf pour ceux qui veulent faire du WireGuard-over-IPoT depuis 1999, mais bon, je m’autorise à penser que ça doit être une niche encore plus réduite que celle des utilisateurs d’OpenPGP. :D

J’ai testé tous mes cas d’utilisation et toute la suite de tests fournis avec le projet lui-même. Pas une seule erreur, tous les tests passent. Pour faire bonne mesure je me suis même amusé à tester avec une version sortie trois ans plus tôt. RAS.

J’ai rien contre l’épinglage de versions précises quand il est justifié, mais ici, on est dans le cas typique d’un développeur qui a épinglé une version arbitraire juste parce qu’il ne voulait pas se casser la tête. (J’ai vérifié l’historique : la contrainte sur le numéro de version a été ajoutée en même temps que la dépendance elle-même — avant même que quelqu’un ait l’occasion de tester avec une autre version et de rapporter un comportement différent, qui aurait pu justifier l’épinglage.)

Je ne vois pas en quoi c’est si difficile à croire, vu qu’on a dans ce même fil des développeurs qui assument clairement faire la même chose — parce que hé ho, hein, bon.

Tu n’es pas obligé d’imposer pour autant une version précise.

Si tu es responsable d’un petit projet et que tes ressources sont limitées, tu peux très bien annoncer clairement la couleur dans le README, genre

Attention, je n’ai testé qu’avec Foo-1.0.3, je ne garantis absolument pas que ça marche avec une autre version. Si vous rencontrez un bug avec une autre version, n’hésitez pas à ouvrir un ticket, mais je ne promets rien.

(Personnellement je ne pense même pas que ce soit nécessaire, pour moi c’est implicite qu’un projet libre fonctionne en mode « best effort », je n’attends pas du développeur qu’il garantisse un fonctionnement parfait en toutes circonstances.)

• Si tu n’imposes pas de version précise : il y a un risque que ton code ne fonctionne pas avec une autre version.
• Si tu imposes une version précise : il est certain que ton code ne fonctionnera pas avec une autre version, vu que pip ne te laissera même pas installer une version [annoncée comme] incompatible¹.

Qu’est-ce qui est préférable ?

---

¹ Parce que bon, moi dans ce cas j’hésite pas à aller éditer le setup.py à la truelle pour virer ce qui me dérange et pouvoir tester avec la version que j’ai sous la main, mais je doute fort que beaucoup se donnent cette peine…

Il n'y a pas que le boulot dans la vie, et c'est d'ailleurs là où j'ai au final toujours le moins sociabilisé dans ma vie.

Moi il n’y a guère qu’au boulot (à l’époque où je travaillais en labo, donc forcément en « présentiel ») que j’ai sociabilisé, comme quoi…

Alors le coup que nous sort tout le temps les gens qui sont fans du travail en entreprise, que c'est mieux pour "sociabiliser" etc., à chaque fois, ça me fait vraiment bien rire!

Tant mieux pour toi. Pour moi dont quasiment tous les amis à deux ou trois exceptions près sont d’anciens collègues, je ne trouve pas ça particulièrement drôle.

Peut-être (sûrement) suis-je socialement inapte, mais je serais un vieil ermite vivant seul dans sa grotte si je n’avais pas pu compter sur le boulot pour me faire des amis.

Je suis aujourd’hui en télétravail et ça me convient très bien, mais ce ne serait pas supportable si je n’avais pas les amis que je me suis fait dans mes précédents postes en présentiel.

Il ne suffit pas que les auteurs de bibliothèques fassent des interfaces propres et pérennes. Il faut encore que ceux qui les utilisent ne fassent pas n’importe quoi.

J’ai eu le cas récemment d’un projet Python qui annonçait (dans la clause requires de son setup.py) dépendre de pyparsing==2.4.7.

J’ai vérifié : il n’y a rien dans le code qui justifie d’exiger cette version plutôt qu’une autre. Pas d’utilisation d’une fonctionnalité qui aurait été introduite avec cette version ou au contraire qui aurait été supprimé des versions suivantes. En fait, le code fonctionne très bien avec PyParsing-3.0.9 (j’ai essayé).

J’ai l’impression qu’au moment de lister ses dépendances, le développeur s’est dit « c’est quoi la version de PyParsing que j’ai sur ma machine ? 2.4.7 ? bon ben on va dépendre de la version 2.4.7 alors, avec celle-là je sais que ça marche… »

Mais à nouveau, comment fais-tu pour tout mettre à jour en même temps ?

Bah c’est pourtant facile, il suffit d’être organisationellement agile qu’on te dit !

« Organisationnellement agile » étant un mot de code pour dire que l’on parle d’une organisation centralisée où toutes les décisions sont prises par un acteur unique. C’est le seul cas de figure où l’approche mono-algorithme est viable, en fait.

Des organisations comme Signal peuvent se permettre de choisir cette approche et de dire merde à l’agilité cryptographique. Mais la présenter comme LA solution universelle applicable partout, c’est stupide.

Supporter l’agilité cryptographique n’implique aucunement de laisser les administrateurs et/ou les utilisateurs décider de l’algorithme à utiliser.

Ce n’est pas parce que c’est comme ça qu’on a fait avec TLS que c’est inhérent au principe de l’agilité cryptographique. (Tous les arguments que j’ai lu contre l’agilité cryptographique sont du même tonneau : on a magistralement foiré l’agilité cryptographique dans (TLS|JWT|SSH|…), du coup il ne faut plus d’agilité du tout…)

Disons que le protocole autorise trois algorithmes différents A, B, et C, et recommande l’algorithme A.

Alice utilise un logiciel supportant les trois algorithmes. Bob utilise un autre logiciel supportant aussi les trois algorithmes. Quand ils se parlent, leurs logiciels s’échangent la liste des algorithmes supportés et, constatant la présence de l’algorithme A des deux côtés, utilisent obligatoirement A, sans que jamais Alice et Bob n’aient leur mot à dire.

On découvre une faille dans l’algorithme A, les auteurs du protocole recommandent désormais l’algorithme B. Alice met à jour son logiciel pour une nouvelle version dans laquelle l’algorithme A est désactivé. Bob n’a pas encore mis à jour (l’éditeur de son logiciel n’a pas encore publié de nouvelle version). Quand ils se parlent, le logiciel d’Alice annonce supporter les algos B et C, le logiciel de Bob annonce toujours supporter les algos A, B, C — les deux se mettent d’accord pour utiliser B, toujours sans que ni Alice ni Bob n’aient leur mot à dire.

Plus tard, Bob met à jour, sa nouvelle version ne supporte plus que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.

Plus tard encore, les auteurs du protocole rajoutent un algo D, et décident qu’il est tellement mieux que les autres qu’il devrait désormais être utilisé partout où c’est possible.

Cette fois l’éditeur du logiciel de Bob est plus rapide et publie une nouvelle version avec le support de D. Alice, elle, reste temporairement avec une version qui ne supporte toujours que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.

Alice met à jour, son logiciel supporte désormais B, C, et D. Alice et Bob utilisent désormais automatiquement D chaque fois qu’ils se parlent.

Et ainsi de suite. À aucun moment Alice et Bob ne peuvent configurer leurs logiciels pour décider eux-mêmes de l’algorithme à utiliser. Le choix est imposé par les logiciels, en fonction des recommandations des auteurs du protocole et de ce que supporte le logiciel d’en face.

Bon, pour le futur, car dans l'immédiat on est engagé

J’ai bien vu que le projet était déjà bien engagé. Je ne suis pas en train de dire « arrêtez tout et repartez à zéro en utilisant une ontologie ! ». ;)

Le problème du monde des ontologies est peut être la complexité perçue de l'extérieur.

C’est pas une perception je te rassure, c’est compliqué aussi vu de l’intérieur. Comment ça c’est pas rassurant ?

L'autre chose pour moi est qu'il me semble qu'on ne définit pas tant des concepts au niveau ontologiques (des classes de concepts) mais plus des instances (un catalogue).

Je n’ai pas cette impression, non.

Si je prends un exemple au hasard sur openfoodfacts.org, l’eau de sources Cristaline 1,5 L, il s’agit bien d’une classe, non d’une instance. Une instance, c’est la bouteille que je pourrais éventuellement avoir en ce moment même dans mon frigo.

un des intérêt majeur pour nous est de traduire en plein de langue et de construire les "synonymes" […] je vois mal comment mettre ça simplement dans une ontologie.

Pour ce qui est des traductions, OWL permet l’utilisation de language tags, donc chaque terme peut très bien avoir un nom et/ou une définition dans autant de langues que tu veux :

AnnotationAssertion(rdfs:label off:123456 "Glass container"@en)
AnnotationAssertion(rdfs:label off:123456 "Bac à verre"@fr)

Pour ce qui est des synonymes, ben il suffit d’avoir une AnnotationProperty prévue à cet effet, comme pour tout le reste. Dans les ontologies biomédicales on utilise (pour des raisons historiques, c’est pas forcément à suivre pour une nouvelle ontologie) http://www.geneontology.org/formats/oboInOwl#hasExactSynonym et ses variantes #hasNarrowSynonym, #hasBroadSynonym, #hasRelatedSynonym :

AnnotationAssertion(oboInOwl:hasRelatedSynonym off:123456 "Cuboverre"@fr)

ça n'apporte pas un fichier facile à éditer, alors que le format actuel est vraiment pensé pour une édition à la mano, donc compacte et assez facile à lire

Là oui, si le but est que ce soit éditable avec un éditeur de texte, effectivement ça va coincer. Il y a bien le format OBO Flat File (qui de très loin est d’ailleurs similaire à votre format maison : c’est un format orienté ligne avec des clauses de la forme tag:valeur), mais c’est un gros héritage historique (il prédate OWL) et personnellement je n’aimerais rien de mieux que de m’en débarasser…

Je connais quelques barbus qui éditent des fichiers en syntaxe fonctionnelle à la main dans Vim ou Emacs, mais à part ces énergumènes-là¹, en pratique travailler sur une ontologie OWL impose quasiment l’utilisation d’un éditeur spécialisé comme Protégé.

un premier pas pourrait être de montrer à quoi ça pourrait ressembler une petite taxonomy en mode ontologie et voir quels outils éventuels ça unlock.

Parmi les « outils que ça débloquerait », ça pourrait par exemple permettre l‘utilisation d’un raisonneur pour automatiser la classification des produits et/ou détecter automatiquement des entrées incorrectes.

Par exemple, si l’ontologie définit un produit végétarien comme un produit ne contenant pas de viande, un raisonneur pourrait automatiquement classifier tous les produits dont aucun ingrédient n’est de la viande comme un produit végétarien, sans nécessiter une classification manuelle. Inversement, si un produit a été manuellement classé comme végétarien mais contient un ingrédient de type viande, le raisonneur détecterait automatiquement l’incohérence.

Tu viens contribuer :-D ?

J’ai peur d’avoir assez à faire avec mes ontologies drosophiliennes.

(Mais c’est pas dit que j’essaye pas quand même. Évite juste de retenir ton souffle en attendant ! ;) )

---

¹ Énergumènes dont il se pourrait que je fasse partie, mais chut, je ne vous ai rien dit.

Mais il me semble que l'agilité cryptographique n'a pas été oubliée.

Si, si. C’est écrit noir-sur-blanc dans le papier blanc de WireGuard :

WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update.

Sachant qu’on compte déjà 8 implémentations indépendantes du protocole (d’après Wikipedia, j’avoue n’avoir pas vérifié), si un jour il faut « demander à tous les nœuds de mettre à jour [en même temps] », ça promet d’être amusant…

En fait, c'est pas pareil mais proche.

Une taxonomie peut être vue comme un sous-ensemble d’une ontologie.

Fondamentalement, une taxonomie, c’est un ensemble de termes reliés entre eux par des relations de type is-a, permettant d’organiser ces termes en une hiérarchie de super-classes et de sous-classes (ou de catégories et de sous-catégories).

Une ontologie, c’est une généralisation du concept de taxonomie, où les relations entre les termes ne sont plus limitées aux seules relations de type is-a, mais sont elles-mêmes des termes de l’ontologie, ce qui permet de décrire des choses beaucoup plus complexe qu’une simple classification hiérarchique.

Et quand je vois ce que semble faire OpenFoodFacts de leurs « taxonomies », il me semble que c’est bien d’une ontologie dont ils ont besoin.

Par exemple, ils ont une « taxonomie » des ingrédients et une « taxonomie » des allergènes, avec la première qui contient des références vers la seconde, comme ici :

<en:starch
en:wheat starch
allergens:en: :en:gluten

Cela indique bien qu’ils ne peuvent se contenter d’une classification hiérarchique : une telle classification permet bien d’indiquer que l’amidon de blé est un type d’amidon, mais ne permet pas d’exprimer la relation avec le gluten. Dans une ontologie, ça se ferait naturellement avec une relation dédiée, qu’on pourrait appeler has-allergen par exemple.

---

Disclaimer : Je suis ontologiste, alors forcément j’ai tendance à « ontologiser » à outrance — vous savez ce que c’est, quand on a un marteau, on voit des clous partout… :D

Indépendamment de la question de Neo4J, un petit commentaire sur OpenFoodFacts et ses « taxonomies ».

Ce que vous appelez une taxonomie, moi j’appelle ça une ontologie. Du coup je me demande si vous avez exploré les options existantes pour créer et manipuler des ontologies.

Quand je vois par exemple que vous avez votre propre format de fichier pour stocker vos « taxonomies », je ne peux pas m’empêcher de penser que vous ré-inventez un peu la roue, alors qu’il existe déjà des formats standards comme OWL 2 (et ses différentes sérialisations), des bibliothèques dans plusieurs langages (OWL API en Java, Pronto en Python, Horned-OWL en Rust…), des éditeurs graphiques comme Protégé…

Outre la ré-utilisation de code et d’outils existants, une « taxonomie » sous la forme d’une ontologie standard favoriserait aussi la collaboration avec des projets comme la Food Ontology par exemple.

Du coup je me demande :

• Est-ce un oversight (pardon, mais ce ne serait pas la première fois qu’on se lance dans un projet en oubliant de regarder ce qui existe déjà¹) ?
• Ou bien avez-vous bel et bien considéré les options existantes, mais conclu qu’elles ne convenaient pas (auquel cas je serais sincèrement curieux d’en connaître les raisons) ?

---

¹ Moi-même, je me suis déjà rendu coupable de ça… :D

J’ai connu exactement la même chose il y a quelques mois quand j’ai voulu essayer Neo4J sur ma propre machine. Un des projets auxquels je contribue (Virtual Fly Brain) repose sur une base de données Neo4J et je voulais pouvoir expérimenter à ma guise, notamment pour apprendre le langage Cypher. Grosse déception au moment de me rendre compte que la version community est limitée à une seule base !

Pour ce que ça vaut, un workaround (sale, mais qui fonctionne très bien avec la version community) est de lancer plusieurs instances du serveur, avec chacune son fichier de configuration et son dossier de données, et écoutant sur des ports différents. C’est loin d’être idéal, mais comme je ne m’en sers que pour expérimenter, ça fait l’affaire, faute de mieux.

Néanmoins, j’évite au maximum de m’en servir — juste ce dont j’ai besoin pour faire ce que j’ai à faire sur VFB, qui est le seul projet sur lequel je travaille à utiliser Neo4J.

Pour le reste, je me tourne plutôt vers des bibliothèques de manipulation de graphes RDF (et vers SPARQL comme langage de requête), comme Jena (Java) ou RDFLib et RDFLib-Endpoint (Python).

Ah pardon, ~60 000 € ça c’était la semaine dernière. Aujourd’hui on est plutôt sur ~52 000 €.

Du coup j’étais mauvaise langue, c’est beaucoup plus abordable que je ne le laissais croire ⸮

Selon l'auteur c'est un des points faible du proof of stake, il va y avoir mécaniquement un effet d'accumulation sur quelques acteurs (ceux qui ont les moyens d'investir, de mobiliser de la monnaie en participation), ce qui est déjà un peu le cas avec la preuve de travail

C’est déjà complètement le cas avec la preuve de travail, concrètement.

La preuve d’enjeu a au moins le mérite, outre la réduction de la consommation énergétique, de rendre les choses plus franches. Pour devenir validateur de blocs, il faut investir 32 ethers, soit environ 60 000 € — du coup au moins c’est clair, c’est pas pour tout le monde. Mais dans les faits ce n’est pas pire que la preuve de travail, juste moins hypocrite.

J’avais cru comprendre que ça faisait partie des motifs de pénalité, mais je n’en retrouve trace nulle part. Au contraire, la description de GASPER, le protocole de preuve d’enjeu d’Ethereum, annonce que le protocole a pour objectif (entre autres) d’assurer que

an honest validator following the protocol will never accidentally violate the slashing conditions.

Donc ce point était sans doute une sur-interprétation de ma part, autant pour moi.

Plus j’y pense, plus ce « bien entendu » me met en rogne…

« La mission est bien entendu persuadée » — ben oui, le Grand Chef a décidé qu’il fallait faire de la France une « nation de la blockchain », alors bien entendu qu’on a pris soin de rassembler une équipe composée uniquement de personnes déjà convaincues que l’idée du Grand Chef est excellente.

Bien entendu qu’il n’y aura pas la moindre voix discordante, pas le moindre contradicteur, pas la moindre personne pour se demander si, au fond, c’est vraiment une bonne idée.

(Et quand bien même on se serait gouré et qu’on aurait invité par erreur quelqu’un d’un peu trop critique, de toute façon on a aussi bien pris soin de cadrer le champ d’investigation — on n’est jamais trop prudent !)

Sinon je te renvoie vers le joli document (avril 2021) du groupe de travail de la DGE, y'a plein d'infos.

Plein d’info sur comment faire de la France une « nation de la blockchain »¹.

Pas un mot sur ce à quoi ça pourrait bien servir. Tout juste une section de quatre paragraphes (« 1.1.4 De l’intérêt des technologies blockchain ») qui explicitement ne répond pas à la question :

La mission est bien entendu persuadée qu’une blockchain ou plutôt une « plateforme blockchain » fournit un ensemble de fonctionnalités qui peuvent trouver de belles applications […] hors des aspects crypto-monnaies et spéculatifs qui lui font parfois une assez mauvaise publicité. Savoir quelles applications sont les mieux adaptées à une telle plateforme n’était pas dans le champ d’investigation de notre mission

« On n’est pas foutu de donner un exemple de “belle application”, mais trust me bro, on est sûr qu’il y en a et qu’il faut faire de la France une “nation de la blockchain” PARCE QUE C’EST NOTRE PROJEEEEEEEEET MISSIOOOOOOOOON. »

même si quelques pistes peuvent être trouvées dans ce rapport.

Voix du narrateur : Il n’y avait, en réalité, pas l’ombre d’une piste dans ce rapport.

---

¹ Le coup du « nation de la blockchain » est véridique, c’est même pas moi qui caricature.