Cette après-midi, j’ai enfin pu vous partager la toute première partie d’un contenu de formation que je prévoyais de partager depuis plusieurs mois.

Cette publication a pris du temps pour plusieurs raisons, mais la principale est que je ne voulais pas seulement republier du texte simple avec quelques exercices, mais un contenu ludique, en m’appuyant sur quelques fonctionnalités de Nostr.

Vous pourrez la retrouver via votre client Nostr favori. En attendant, voici le lien avec mon client favoris, Yakihonne : Formation Linux et Cloud – le plan de la formation.

Si vous avez parcouru le résultat, vous vous douterez que je n’ai pas atteint mon objectif 😅 Je n’ai pas abandonné pour autant, mais je voulais vous partager un retour d’expérience sur ce projet 😉

Quel était le but ?

Le point de départ de ce projet était un constat : autour de moi, je voyais des développeurs sachant très bien coder… Mais seulement coder. Dès qu’il s’agissait de mettre les mains dans la CI, ou de comprendre comment leur application était déployée, il n’y avait plus personne.

Or, Martin Fowler l’avait déjà très bien compris : ce n’est pas une position tenable sur le temps long. « Les personnes qui ne travaillent que dans un seul quartier technologique courent le risque permanent de s’enfermer dans un silo de connaissances, ignorant de nombreux outils qui pourraient les aider dans leur travail. » L’expert sera certes doué dans son domaine, mais ne sera pas autonome en dehors de celui-ci.

Et aujourd’hui, la situation ne s’arrange pas avec l’IA, car simplement coder perd progressivement en intérêt : nous pouvons déléguer ces tâches à des agents experts, tandis que nous devrons nous consacrer à d’autres tâches à plus forte valeur : compréhension du besoin, conception et design de la solution, pilotage des agents (à la manière d’un architecte ou d’un tech lead avec des codeurs aujourd’hui), contrôle des résultats, etc. Bref, l’humain et le créatif vont prendre le pas, car ces missions ne pourrons jamais être assumées à 100% par l’IA.

Par contre, l’IA ne sera jamais infaillible. Et c’est là où les développeurs d’hier et les vibecoders d’aujourd’hui (et probablement encore demain) font face aux mêmes défis : avec l’IA, comprendre l’environnement et l’architecture sont essentiels, mais pour être capable de comprendre ce que l’IA produit, et être capable de corriger ses erreurs.

Quel était le plan ?

Depuis quelques mois déjà, je suis avec beaucoup d’intérêt les progrès de Nostr. Au début ce protocole se concentrait sur la publication de notes et d’articles, et permettait par extension de publier des messages privés.

Sa logique est simple : bâtie sur la logique de blockchain, chaque message est enregistré et horodaté de telle sorte que l’historique des publications est infalsifiable. L’authenticité des messages est garantie par une paire de clés selon le principe du chiffrement asymétrique : tout message chiffré avec ma clé privée ne peut être déchiffré qu’avec ma clé publique. Et comme mes messages sont chiffrés avec ma clé privée sur la chaîne, n’importe qui peut certifier que je suis l’auteur de ces messages avec ma clé publique.

Mais Nostr ne s’est pas arrêté là. L’objet de base stocké sur la chaîne dispose d’une certaine souplesse, de sorte que nous pouvons publier bien plus que de simples messages texte. Cette polyvalence du protocole m’a déjà permis de publier mes articles jusqu’à présent, aussi bien que sur Substack.

Yakihonne, le client Nostr que que j’utilise au quotidien permet également de « programmer » des widgets sur la chaîne. Pour celà, la plateforme propose des « smart widgets » qui permettent de stocker une mini-application à la place d’un simple message. Cette application pourra exécuter des tâches spécifiques au chargement par le client, ou lorsque l’utilisateur décide de cliquer sur l’un des boutons intégrés au widget…

Quels ont été les embûches ?

Curation : un sommaire dynamique ?

L’un des premiers types de widget que j’ai voulu tester a été la curation. En gros, il s’agit d’un outil d’agrégation de contenu, nous permettant d’organiser et de partager des collections d’articles, de notes et d’autres médias.

Mon but était de concevoir la page d’accueil de ma formation avec une curation : un texte de présentation, accompagné de la liste des chapitres ordonnés en dessous.

Cependant, j’ai été confronté à deux limitations des curations.

• Tout d’abord, le bloc de texte au dessus de la liste de publication est extrêmement limité, sans mise en forme. C’est littéralement prévu pour une accroche, rien de plus. Exit donc le long passage d’introduction à ma formation.
• Le second, je penses que c’est plus un bug qu’autre chose : impossible de récupérer des publications postérieures à fin avril. Le formulaire (comprimé dans une modale) propose un menu pour sélectionner les publications avec possibilité de filtrer sur ses propres publications, soit sur le « naddr » de sa publication (son identifiant unique sur Nostr). Toutes mes publications récentes n’apparaissent pas, et si je fourni directement son naddr, la recherche échoue (impossible de trouver l’article).

Je me suis finalement rabattu sur un article classique comme porte d’entrée de ma formation… Au final, cela marche tout aussi bien !

Un QCM sexy avec un widget… ou pas ?

Comme vu précédemment, les « smart widgets » de Yakihonne permettent de créer des mini-applications, notamment avec une illustration (obligatoire), un champ de saisi optionnel, et plusieurs boutons (jusqu’à 6).

Autrement dit, il est possible de créer des formulaires simples qui seront chargés directement sur le client de l’utilisateur. J’avais dans l’idée de m’en servir pour rendre mes QCM plus ergonomiques et ludiques… Sauf que voilà.

Déjà, l’illustration obligatoire était un frein pour moi : je n’allais pas m’amuser à créer une image par question de mes QCM (faites le compte : 5 chapitres, 12 questions par chapitre… 60 images ?). Ensuite, impossible de fournir du texte (qui aurait été plus simple à intégrer à la place de l’image).

Ensuite, les boutons doivent déclencher soit une actions prédéterminée (redirection vers une url, envoi de quelques satoshis, événement Nostr spécifique,…). Dans mon cas, il aurait fallut que j’anticipe le coup en développant une API capable de recevoir les événements et de comptabiliser les scores, en quelques sortes. Chose que je n’avais pas prévu. Après, Yakihonne propose des SDK (kits de développements), mais là aussi, plus de temps sera nécessaire pour explorer ces fonctionnalités.

L’input étant optionnel, pas de soucis de ce côté là, mais ça m’a donné des idées que j’explorerai lorsque je maîtriserai mieux les widgets Yakihonne (notamment, j’ai vu des gens tester une IA capable de répondre derrière le clic sur le bouton).

Et maintenant ? Le plan pour la suite…

Dommage, car en fin de compte, je suis coincé entre un manque de temps pour approfondir une fonctionnalité qui a l’air vraiment sympa, et un manque d’ergonomie, qui risque de rebuter des utilisateurs encore plus néophytes que moi…

Gageons que ce point soit rapidement réglé, dans le futur !

Et c’est pourquoi je ne lâcherai pas l’affaire de si tôt. Pour moi, la prochaine étape va être un arbitrage entre deux ambitions :

• d’une part monter en compétence sur Nostr, en explorant plus en détail le fonctionnement des widgets de Yakihonne (entre autres, car j’ai également vu circuler quelques projets sympathiques) ;
• d’autre part, continuer à distribuer mes supports de formation Linux, Cloud, et Product Management.

À dire vrai, vous serez les arbitres du duel : voulez-vous en savoir plus sur Nostr, ou plus de contenu Cloud et Product ?

Sources

• L’expert généraliste, de Martin Fowler.
• Yakihonne explique les Smart widgets