Esprit de partage
Définition
L'esprit de partage, c'est la volonté sincère de transmettre ce qu'on sait, de rendre accessible ce qu'on a construit, et de contribuer à la progression des autres sans en attendre quelque chose en retour. Dans l'écosystème du logiciel libre et de la cybersécurité, c'est une valeur fondatrice : une grande partie des outils, des documentations et des pratiques qui structurent le métier existent uniquement parce que des gens ont choisi de partager plutôt que de garder pour eux.
Pour moi, partager ne se limite pas à publier du code. C'est expliquer la logique derrière une décision technique, accompagner quelqu'un qui bloque sur un problème, ou documenter un projet pour que quelqu'un d'autre puisse s'en emparer sans avoir à tout redécouvrir from scratch.
Dans le contexte actuel, où les chaînes d'approvisionnement open source sont devenues centrales dans toutes les infrastructures (xz, OpenSSL, log4j ont rappelé que des composants maintenus par quelques bénévoles tiennent une partie d'Internet), l'esprit de partage n'est plus un supplément d'âme : c'est l'une des forces qui maintient l'écosystème technique en état de marche. Mon engagement dans cette direction est cohérent avec mon objectif personnel de devenir contributeur reconnu de l'écosystème libre.
La compétence en pratique
Aider régulièrement des camarades à débloquer leurs problèmes techniques
Au quotidien, j'aide régulièrement d'autres apprenants de ma promotion à l'ESIEA lorsqu'ils rencontrent des difficultés. Que ce soit sur des problèmes de configuration réseau, des questions de scripting, des blocages sur des projets de lab, ou des sujets de cybersécurité que j'ai pratiqués avant eux, je prends le temps d'expliquer la logique plutôt que de donner simplement la réponse.
Pour moi, donner la réponse directement ne fait pas progresser. Comprendre pourquoi, si. C'est une discipline que je m'impose même quand ça me coûte du temps : je préfère poser deux ou trois questions ouvertes pour que la personne arrive elle-même à la solution, plutôt que de balancer la commande exacte qui résout son problème. Cette posture rend les sessions d'aide plus longues mais beaucoup plus formatrices pour la personne qui demande.
Publier ses outils plutôt que de les garder pour soi
Mon projet Docker-IDS-Sensor est construit dans une logique de réutilisabilité dès le départ. Publier le projet sur GitHub plutôt que de le garder en privé est en soi un acte de partage : l'objectif n'est pas simplement de versionner mon code, c'est de produire quelque chose qu'une autre personne peut comprendre, utiliser et améliorer sans avoir besoin de me solliciter.
La documentation, la structure du dépôt et les choix d'architecture reflètent cette intention : un README structuré, un docker-compose qui s'auto-explique, des Dockerfiles compréhensibles. C'est un investissement en temps significatif (probablement 30% du temps total du projet est passé sur la documentation et la propreté du code) que j'aurais pu économiser si j'avais publié sans intention de partage réel.
Cultiver un échange horizontal avec une communauté de pairs
J'entretiens des échanges réguliers avec une équipe de pentesters sur Keybase, dans une dynamique de partage mutuel. Ils me transmettent leur expérience terrain, je partage mes retours sur des outils ou des configurations que j'ai testés, des découvertes en CTF, des analyses de papers ou d'incidents publics. C'est ce type d'échange, horizontal et sans ego, qui fait vraiment avancer.
Cette communauté n'est pas un canal de support à sens unique : chacun y apporte ce qu'il sait, et reçoit en retour. C'est exactement ce que j'aimerais retrouver à plus grande échelle dans les projets open source structurés. C'est aussi dans ce cadre informel que j'ai validé beaucoup d'apprentissages techniques en les confrontant à des praticiens plus expérimentés que moi, ce qui évite les angles morts qu'une autoformation pure peut produire.
Mon niveau de maîtrise
Mon esprit de partage est sincère et présent au quotidien, mais encore limité dans sa portée publique. Je partage volontiers dans mon entourage proche et via GitHub, sans encore avoir contribué formellement à des projets communautaires structurés. Mes contributions publiques restent modestes en termes de visibilité et d'audience.
Contextualisation : je suis conscient que partager dans un cercle restreint, c'est bien, mais que l'impact réel vient quand on s'ouvre à des communautés plus larges. C'est précisément la zone que je veux travailler dans les prochains mois et années.
Place dans mon profil et vitesse d'acquisition
L'esprit de partage est une compétence identitaire pour moi : elle est cohérente avec mon objectif personnel de devenir contributeur reconnu de l'écosystème libre, et c'est une valeur que je considère comme structurelle dans ma définition de ce qu'est un bon ingénieur. Sans esprit de partage, on construit des silos personnels qui ne survivent pas au départ de la personne qui les a montés.
Vitesse d'acquisition : cette compétence n'a pas eu de pic d'apprentissage, c'est une disposition cultivée progressivement. Ce qui a évolué avec l'expérience, c'est la qualité technique de mes partages : ma documentation aujourd'hui est sensiblement meilleure qu'il y a 2 ans, mes explications à l'oral plus structurées, mes échanges techniques plus précis. C'est cette qualité qui transforme l'intention de partager en partage réellement utile.
Mon recul sur la compétence
Avec l'expérience que j'ai aujourd'hui, je conseille de partager même quand on se sent illégitime. Beaucoup de gens attendent d'avoir « le niveau » pour publier quelque chose, et ce niveau n'arrive jamais. La vérité, c'est qu'il y aura toujours quelqu'un de plus expérimenté que vous, mais il y aura aussi toujours quelqu'un qui apprend exactement les notions que vous maîtrisez. Pour cette seconde personne, votre partage a une valeur réelle, indépendamment de ce que pensent les seniors.
Je conseille aussi de documenter pour soi-même d'abord. Quand on documente un projet en se mettant à la place d'un futur soi qui n'aura plus le contexte, on documente bien. Quand on documente en pensant aux autres, on documente trop ou trop peu. Cette inversion de perspective a transformé la qualité de mes READMEs.
Enfin, je conseille d'expliquer la logique plutôt que la commande. Donner la solution exacte à un problème, c'est aider une fois. Expliquer la méthode qui mène à la solution, c'est apprendre à pêcher au lieu de donner le poisson. Cette discipline coûte plus de temps sur le moment mais paie largement sur la durée, à la fois pour la personne aidée et pour la qualité de la relation qui s'établit.
Évolution et formations
Mon objectif à moyen terme est de m'inscrire durablement dans des communautés open source actives, en passant du statut d'utilisateur à celui de contributeur reconnu. Cela implique de proposer des correctifs, de documenter des problèmes, de participer aux discussions et à terme de maintenir des composants dans des projets existants.
C'est dans cette logique que s'inscrit mon travail actuel sur mes outils personnels : les rendre suffisamment matures et documentés pour pouvoir les proposer à des communautés plus larges, et commencer à exister en dehors de mon cercle immédiat.
Concrètement, mes cibles de contribution open source à court et moyen terme sont des projets que j'utilise quotidiennement : modules ou règles pour Suricata et Wazuh, améliorations de scripts d'installation Alpine, ou paquets Debian que je connais bien pour les avoir installés des dizaines de fois. Plutôt que de viser tout de suite des contributions majeures, je préfère commencer par des contributions modestes (typos dans la documentation, signalements de bugs avec reproduction propre, petits correctifs) pour apprendre les codes de chaque communauté avant d'y prendre une place plus significative.
Sur le plan des apprentissages formels, je n'ai pas pour stratégie de me former par lectures sur la communication ou la transmission. Mon mode d'apprentissage reste basé sur la pratique terrain et la veille active. Je tiens un système de notes personnel structuré (Obsidian privé) qui me sert à la fois à organiser ma propre réflexion et à produire de meilleures explications à l'oral : ce qu'on a structuré pour soi, on l'explique mieux aux autres. C'est probablement l'investissement à plus fort rendement que j'ai fait sur cette compétence ces deux dernières années.
Réalisations rattachées
Cette compétence est mobilisée principalement dans deux réalisations. La Sonde IDS conteneurisée matérialise un partage open source structuré, depuis la conception jusqu'à la documentation utilisateur. Le Portfolio auto-hébergé est lui-même un acte de partage : rendre publiquement accessible le détail de mes compétences, projets et réflexions techniques.