Dans ce billet, je parlerai de documentation d'administrateur système, une documentation reposant sur du texte : les commandes shell (par exemple) restent du texte ; il n'y pas de schéma réseau ou autre (ou alors sous forme d'image intégrée). L'idée ici est de résumé un peu toute l'importance de la documentation, sujet souvent négligé par manque de temps, parce que l'on pense que c'est inutile etc.

Objectif premier de la document : Prévenir la perte d'information

Pour moi, l'objectif premier est de prévenir la perte d'information. J'évoquais dans mon billet Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1, l'héritage d'une infrastructure existante vieillissante, sur laquelle des générations d'administrateurs systèmes se sont succédés, et avec eux, la perte d'information.

En effet, la plupart du temps, la transmission de connaissances se fait (ou ne se fait pas) de façon orale au sein des membres de l'équipe Lorsque ces derniers partent vers d'autres horizons, même s'il y a eu une phase de passation de connaissances, il y aura toujours une perte d'information...

Toute modification et évolution doit donc être tracée dans la foulée et non "plus tard quand on aura le temps". Sinon, ce ne sera jamais fait et c'est le début d'un cercle vicieux et infernal, et le début de la fin de la documentation…

Et ce n'est pas le jour où l'on aura besoin d'une information qu'il faut se rendre compte qu'on ne la possède plus...

Documentation : définir un standard, une charte

Pour avoir une documentation de qualité uniforme, il faut définir des standards, une sorte de charte d'écriture de la documentation, des conventions. Un exemple valant mieux qu'un long discours, je vous renvoie vers la page Conventions pour le wiki Evolix que je trouve très bien. Ont été définies les règles de nommages, les conventions pour les commandes shell, les adresses réseaux etc.
Il faut également penser à avoir un sommaire, un chapitrage (chapitre et sous-chapitre), pour organiser la documentation de façon structurée.

Documentation, documentation, documentation

Il faut trouver un équilibre en ne rien documenter et trop documenter. Mais la documentation est à faire. Vaut mieux peu de documentation que pas de documentation du tout, mais vaut également mieux de la documentation utile que trop riche et inexploitable. Pour éviter d'aller trop dans le détail, on peut par exemple indiquer des prérequis, renvoyer vers des pages existantes pour avoir plus d'informations.
Il faut que la documentation se suffise à elle-même. Mais il ne faut pas réinventer la roue à chaque fois, et il ne faut pas hésiter à faire des renvois vers d'autres pages qui expliquent en détails, vers les documentations officielles. Les liens vers des sites extérieurs peuvent être mis en complément d'information mais le contenu doit rester disponible, car si le site est temporairement indisponible ou ferme de façon définitive, on perd l'information. Je conseillerai alors de recopier des bouts de tutoriaux existants, pour se les approprier, et avoir une uniformité dans la documentation.

Documenter pour les autres

Quand on écrit une documentation, il faut penser avant tout à l'écrire pour les autres. Ce qui nous semble évident ne l'est pas forcément pour quelqu'un d'autre, il ne faut pas faire de sous-entendu. Le choix des mots est important : ne pas hésiter à mettre plusieurs mots différents dans le titre, d'autant plus s'il y a un système de recherche par mot clefs.

Il faut que la personne qui lise la documentation ait un minimum de bagage technique et l'indication de prérequis : on ne va pas réexpliquer chaque commande Shell, donner un cours de Linux ou autre.

Il faut généraliser les explications, les commandes, sauf cas particulier : idéalement, une documentation sur un sujet donné doit être applicable à l'ensemble des serveurs de l'entreprise. On essaiera autant que possible de mettre des utilisateurs génériques, des IP par défaut etc. cf la charte de l'écriture de la documentation.

Les conseils :
faire relire la documentation écrite par quelqu'un d'autre ;
lui faire rejouer les commandes pour valider que tout marche bien.

Documenter, c'est bien. Maintenir à jour la documentation, c'est mieux

Documenter c'est bien mais sans maintenir la documentation à jour ça ne sert à rien. Là encore, il faut trouver un équilibre. Je conseille d'indiquer une date de dernière mise à jour des informations par exemple, pour pouvoir juger au premier coup d'œil de l'obsolescence potentielle de l'information.

On peut envisager une revue de documentation régulière, un passage en revue en se basant sur la date de dernière mise à jour pour vérifier si les informations sont toujours correctes, utiles. Normalement si la documentation est bien maintenue à jour au fil de l'eau, oui, il n'y a pas de pas obsolètes ou incorrectes. Mais comme on est parfois amené à travailler dans l'urgence, que tout le monde n'a pas la même rigueur etc. cette revue de documentation n'est pas inutile.

Documenter, mais avec quel outil ?

Sur ce point, je vous renvoie vers le billet que j'avais écrit Je vous renvoie vers mon billet Lifehacking - Gitlab, outil idéal ? et plus particulièrement sur la partie concernant le wiki. En quelques mots, je conseille de trouver un outil facile, pérenne dans le temps, qui sera facilement adopté par tous.

Les critères à prendre en compte sont :
multi-utilisateurs et possibilité d'éditer la documentation à plusieurs : le wiki Gitlab repose sur les utilisateurs Gitlab. On a un wiki par projet. On peut éditer à plusieurs, mais à tour de rôle.
accessible hors ligne : avoir un wiki en ligne (en mode web), c'est pratique car c'est centralisé. Mais le jour où on perd la connexion réseau et que les informations pour rétablir le réseau sont sur le wiki en ligne, on est bien embêté (c'est du vécu). L'avantage d'un wiki dans Gitlab est que l'on peut cloner le wiki en local et donc avoir la documentation en mode hors-ligne.
historisation : le wiki de Gitlab repose sur Git, on a donc bien l'historisation des pages et un suivi des modifications possibles.
liens entres les pages : des liens hypertextes pouvant être faits pour renvoyer vers les différentes pages du wiki en lui-même, vers des liens externes (dès lors que l'on a une url).
possibilité d'ajouter des images, des documents : il est possible d'intégrer des images directement dans le corps du texte dans le mode édition depuis le navigateur. Il est possible de faire un lien hypertexte vers un document ou un fichier qui est stocké dans un des dépôts d'un projet dans l'instance Gitlab.
un système de recherche : il faut pouvoir recherche à base de mots clefs pour retrouver les différentes pages abordant un sujet particulier.

Sauvegarde de la documentation

Comme toutes données, la documentation doit être intégrée à la politique de sauvegarde, il faut valider que l'on sait restaurer cette documentation etc...

Conclusion

Rien ne remplacera l'expérience acquise, mais on ne peut pas tout savoir et tout retenir. De ce fait, la documentation est importante. Dans ce billet je n'abordais que l'aspect documentation du point de vue de l'administrateur système, mais beaucoup des conseils et recommandations sont aussi valables pour d'autres métiers de l'informatique (développeur par exemple), et sont sûrement adaptables et généralisables à d'autres corps de métiers.

Le résumé des épisodes précédents a été fait dans une conférence Conférence Du pseudonymat au pseudonyme et les nombreux billets publiés sur le sujet sur ce blog.

Après quelques mois, et le billet de blog Un canal de communication privé ? dans lequel j'aborde le fait de me restreindre un peu, j'avais fait une expérimentation. Celle de verrouiller mes comptes de réseaux sociaux pour ne rendre visible mes messages qu'aux abonnés. Mais ça n'a duré que quelques semaines. Cette fermeture, je la voyais comme une forme d'auto-censure. Du coup, au cours de l'été, je suis passé à un autre mode, ré-ouvrant en public mes comptes, mais abandonnant la publication de tout message lié à mon entreprise sur mon compte pseudonyme.

Pour participer à la communication de l'entreprise sur les réseaux sociaux, pour relayer les messages institutionnels et partagés des messages liés à mon entreprise, j'ai récréé un compte sous mon identité civile sur Twitter. Puis j'ai entrepris de me désabonner des comptes des personnes travaillant dans la même entreprise que moi (souvent des comptes sous leur identité civile), pour mieux me réabonner à ces mêmes comptes sur mon compte "Professionnel". Et ces mêmes personnes se sont à leur tour abonner à mon nouveau compte.

J'ai alors commencé à gérer les deux comptes via le même navigateur, mais en utilisant les onglets contextuels de Firefox (pour le détail sur cette fonctionnalité, voir ici). Mon pseudonymat est devenu pseudonyme et donc les précautions liés à la préservation de ce pseudonymat n'ont plus lieu d'être, l'usage depuis un même PC et un même navigateur, une même IP etc. sont acceptables. Mon blog est mon espace personnel. Même si j'y publie des retours d'expérience lié à mon métier, à mon expérience professionnelle, je ne mentionne pas l'entreprise, je ne parle pas de clients précis, je fais des généralités. Cette séparation marche plutôt bien et c'est une bonne chose. Et je sais la chance que j'ai. Il en est de même pour les réseaux sociaux.

Après être reparti sur une séparation des comptes sociaux, dont le cloisonnement est d'une certaine façon, assez fictif, avec les semaines et le fait que j'ai tous les messages de mon entreprise sur un compte dédié, j'ai de fait oublié que les personnes de mon entreprise me suivent (encore) sur les deux comptes du coup. Si vous avez bien suivi, je n'ai bloqué personne (j'aurai pu), par choix. Ce que je publie sur mon compte personnel est publique et bloquer certaines personnes (et pas d'autres), c'était pour moi, une forme de censure. De plus, mes messages publics renvoient également vers des billets du blog, eux-mêmes publics... Donc il faudrait arrêter de publier sur le blog, inenvisageable... A la divulgation de mon identité et à mon passage du pseudonymat au pseudonyme, lors de mon entretien d'embauche il y a un peu plus de deux ans, j'avais demandé et je persiste à vouloir que la séparation sphère personnelle publique, publique mais personnelle versus sphère professionnelle publique soit respectée. Et c'est le cas.

Sur mon compte personnel public j'ai publié un lien vers mon billet sur la cyclothymie. Et en message, j'ai, entre autre, eu deux retours de la direction (mes responsables directs). Sentiment étrange. Ils savent que je suis comme ça car l'un d'eux avait même utilisé cette qualification pour me parler des hauts et bas durant ma période difficile en juin (cf Retour après deux mois de silence). Les messages étaient très clairement une forme de soutien, sur le fait d'assumer ce que je suis. Mais cela m'a toute de même fait bizarre et rappelé que plus jamais Genma ne serait un pseudonymat. Et que si je voulais revenir à ce mode, il faudrait alors repartir de zéro. Et quelque part, au fond de moi j'ai eu comme le sentiment de la fin d'une époque définitivement révolue.

Ayant eu à changer de téléphone car l'ancien a fini par donner des soucis matériel sur l'écran, j'ai repris un portable d'un ami d'occasion encore fonctionnel. C'est là l'occasion de faire le tri sur les applications que l'on utilise vraiment au quotidien.

Dans le présent billet, j'aborderai donc la configuration / paramétrage des différentes applications que j'utilise "en mode cloud", comprendre : les applications tournent sur mon serveur sous Yunohost et les applications clientes sont installées sur l'ordiphone - smartphone.
Toutes ces applications sont disponibles sur F-Droid ou via les APK du Google Store récupérable via une application comme YALP.
Ce billet n'est pas un tutoriel, plus une prise de notes de type wiki pour avoir sur une même page les différentes configurations. Je pars du principe que vous savez installer l'application, saisir les bonnes informations dans les bons champs.

NextCloud - Utilisation de l'agenda et des contacts. Application : Davdroid

J'utilise NextCloud pour la gestion de différents agendas et mes contacts. La synchronisation sur le téléphone passe par l'application Davdroid.

Paramétrage de l'application :
URL : https://url.de.nextcloud/remote.php/dav/
L'utilisateur : celui de Yunohost
Pass : celui de Yunohost
Lien vers Davdroid sur F-Droid.

Les contacts sont alors synchronisés dans l'application Contact par défaut du téléphone, les agendas dans l'application Agenda par défaut. Dans mon cas, j'installe comme application d'agenda l'application Etar.

NextCloud l'application client

L'application Client NextCloud permet de synchroniser les fichiers et d'avoir certains d'entre eux en mode déconnecté sur le téléphone.

Paramétrage de l'application :
Serveur : https://url.de.nextcloud/
User : celui de Yunohost
Pass : celui de Yunohost
Lien vers NextCloud l'application client sur F-Droid.

NextCloud notes

Dans NextCloud j'ai installé l'application Notes.

Paramétrage de l'application :
Serveur : https://url.de.nextcloud/
User : celui de Yunohost
Pass : celui de Yunohost
Lien vers NextCloud notes sur F-Droid.

Remarque : les notes qui apparaissent dans l'application Notes sont elles-mêmes de simples fichiers .txt, qui se trouvent dans l'application Fichier, dans le dossier Notes. L'application client de synchronisation permet également de synchroniser ce dossier et donc d'éditer ses notes via un éditeur de texte sur un PC par exemple.

FreshRSS, l'agrégateur RSS. Application : EasyRSS

L'application EasyRSS permet de se connecter à différents agrégateurs RSS en ligne, dont FreshRSS.

Une configuration préalable dans FreshRSS est à faire, il faut avoir penser à cocher l'autorisation de l'accès à l'API et penser à créer un mot de passe dédié pour l'API. Voir mon tutoriel : Yunohost, FreshRSS et EasyRSS pour Android.

Paramétrage de l'application :
Serveur : https://rss.mondomaine.org/api/greader.php
user : celui de Yunohost
pass : clef d'API définie dans la configuration de FreshRSS
Lien vers EasyRSS sur F-Droid.

Wallabag. Application : Wallabag

Une configuration préalable dans Wallabag est à faire, il faut aller dans la partie "API clients management" et créer un nouveau client.
URL : https://wallabag.genma.org/
L'utilisateur : genma@genma.org
Pass : celui de yunohost
Lien vers Wallabag sur F-Droid.

Introduction

Avant d'être amené à être chef d'équipe et directeur de service, je n'avais jamais été chef d'équipe et je n'avais jamais eu de formation sur le sujet du "management". J'avais bien évidement travaillé en équipe. Dans un premier temps, on pense qu'être un chef d'équipe est intuitif, simple, qu'il suffit de reproduire ce que l'on aimait bien chez des chefs de projets et d'équipe dans leur façon de gérer une équipe. En fait non.

Le présent billet ne racontera pas mon parcours mais sera une synthèse des bonnes pratiques et des choses à éviter, issue de mon expérience. Je ne cacherai pas que cette expérience est basée sur des choses positives mais aussi des choses négatives. Et sur beaucoup des conseils que j'ai pu avoir et que j'ai
lors de mon accompagnement et point de suivi hebdomadaire avec la R.H.

Après avoir eu à superviser jusqu'à quasi une dizaine de personnes, et je passais plus de temps à faire le suivi des affectations sur projets et des emplois du temps, j'ai désormais une toute petite équipe avec laquelle je travaille 8h par jour, j'interagis autant que possible avec eux. Un apprenti et un stagiaire. Et cette micro-équipe permet du micro-management. Nous sommes productifs, nous avançons à un bon rythme sur les chantiers en cours et à venir. Et surtout, nous aimons notre travail, ce que nous faisons jour après jour, semaine après semaine.

Le présent billet parlera beaucoup de productivité, de collaborateur etc. , soit un vocabulaire très "management", entreprise. Mais il faut bien comprendre que j'ai des responsabilités, des comptes à rendre à la direction de mon entreprise, que les membres de mon équipe ne sont pas mes amis mais des employés de l'entreprise, ont une relation de subordination vis-à-vis de moi et vis-à-vis de l'entreprise qui les rémunèrent. La relation n'est donc pas une relation d'égale à égale etc. Toutefois j'espère que la suite de ce billet montrera l'importance qu'à l'humain au cœur de tout ça et que mes bonnes pratiques quotidiennes de chef d'équipe, ont autant pour but que tout ce passe bien pour l'entreprise que le fait que tout ce passe bien pour mon équipe.

Les pronoms ont leur importance dans mon texte :
le je exprime le fait que je parle de moi,
le on est assez générique et m'implique, moi et mes collaborateurs, mais peut être plus général,
le nous montre que nous sommes une équipe, nous formons un groupe et une communauté.

4 règles simples

Ensemble, nous avons validé 4 règle simples, que nous nous sommes engagés à respecter. Les voici :

Des Objectifs S.M.A.R.T. Spécifique strong>Mesurable Acceptable Réaliste Temporellement La méthode consiste à identifier des objectifs quantitatifs et/ou qualitatifs sur une période définie.. En résumé, je définis des projets que je découpe en tâche unitaire. Si une tâche est trop complexe, elle est redécoupée en sous-tâche.

Remplir le Kanban Nous avons un Kanban partagé en ligne (voir à ce sujet mon billet Lifehacking - Gitlab, outil idéal ?) Chaque matin, je parcours le Kanban avec l'équipe et définit les priorités, chaque soir, on reparcourt le Kanban, on voit ce qui a bien avancé, ce qui est en attente. Il n'y a surtout pas de concours sur le nombre de tickets. Il y a des tickets qui durent 5 minutes et qui sont fait en appliquant la méthode Getting Things Done : on traite de suite si ça prend moins de 5 minutes, on crée un ticket et on fera plus tard si c'est plus long. Et il y a des tâches qui durent plusieurs heures. Une tâche qui dure plus d'une matinée doit être redécoupée en tâche plus courte. Cf les objectifs S.M.A.R.T.

Toutes nouvelles tâches non prévues qui arrivent dans la journée (souvent liées à des imprévus, impondérables ou sollicitations extérieures diverses et variées) sont ajoutées sur le Kanban par chacun d'entre nous. On applique d'une certaine façon le conseil de Makoto pour les todo-listes.

Dire ce que l'on fait, faire ce que l'on dit. Facile vu qu'on remplit un Kanban en toute transparence. On sait qui fait quoi et est sur quoi, à tout moment.

On est solidaire entre nous Dernier point et non des moindres, notre trio, ce n'est pas chacun pour soit. On doit prendre du temps pour aider l'autre, même si cela nous retarde dans notre propre tâche. Je ne reprocherai jamais à un membre de mon équipe d'avoir aider l'autre. Je demande juste à être informé par la personne en difficulté de ces difficultés et du retard qui s'annonce ; je prends alors sur moi de l'aider ou sollicite l'aide de quelqu'un d'autre pour aider...

Impliquer les collaborateurs

La R.H. m'a appris une chose importante : pour réussir, il faut impliquer les collaborateurs. Donc, pour les impliquer, pour une tâche donnée, j'explique donc :
le pourquoi : pourquoi on doit faire si ou ça, quel est le but à court, moyen et long terme
le comment : comment on va faire ça.
le quand : je donne des délais et valide la faisabilité du délai avec le collaborateur. A la fin du temps, on voit ensemble si la réalisation a été plus rapide, plus longue ou interrompue. On valide ensemble le temps estimé pour finir la tâche.
l'attendu : je définis ce que j'attends, le format et le formalisme, je montre des exemples.

A noter que dans ces pourquoi, comment, quand on retrouve une autre façon de parler de tâche S.M.A.R.T., tout se rejoint.

Pour tout ce qui concerne le choix des technologies permettant de faire cette industrialisation, je partage, j'expose, j'explique, je soumets. Nous pouvons débattre du pour et du contre. Dans tous les cas, je prends la décision finale, je tranche, et j'ai le dernier mot, de par ma position de responsable. Mais je ne choisis pas ce qui m'arrange mais ce qui a fait l'unanimité ou a obtenu un consensus.

Apprendre à faire confiance

Un adage dit On est jamais mieux servi que par soi-même ; j'ai appris à faire confiance et à déléguer et à obtenir ce que j'aurai fait par moi-même voir mieux ! En suivant ces règles d'implication, la personne est plus à même de mieux faire son travail, de s'approprier la tâche, le projet, qui devient sien. Quand je sais que ma façon de faire est plus productive, efficace, j'explique. Je n'impose pas. Je montre qu'en effet ma façon de faire est la meilleure car issue de nombreuses années d'expériences.

Donner l'occasion au collaborateur de se faire sa propre expérience

Dans un prochain billet je parlerai de l'importance de l'expérience, en parlant justement de ma propre expérience et du partage de cette expérience. Se faire sa propre expérience passe aussi par apprendre de l'expérience des autres. Mais il est important aussi de se faire sa propre expérience, et j'essaie autant que possible que mes collaborateurs soient dans ce mode.

Parfois, quand je demande à un collaborateur comment il compte s'y prendre et qu'il m'explique sa démarche, je sais pas avance que ça ne marchera pas. Je le laisse toutefois faire à son idée, si celle-ci ne présente aucun risque, juste une perte de temps. Se casser les dents sur un problème pour ensuite avoir la solution permet d'apprendre de ses erreurs, de se rappeler : c'est plus marquant d'avoir galéré que d'avoir de suite une solution sans comprendre pourquoi c'est ainsi et pas autrement. Vu que l'on aura eu l'occasion de tester autrement, on sait pourquoi c'est comme ça...

Faire passer au tableau

A côté de mon bureau j'ai un tableau blanc (de type velleda) sur lequel j'explique certaines choses, les actions à faire, à base de schémas, de dessins rapides. Ensuite, j'efface et je demande de me réexpliquer ce qui est attendu (principe de la reformulation). Je demande donc reformuler ce que je viens de dire, de résumé pour valider que tout a bien été compris. Et ce n'est pas toujours le cas. Et je m'aperçois alors que tout n'était pas aussi simple et facile à comprendre que je ne le pensais. Alors je réexplique à nouveau.

Parfois, je demande qu'on m'explique un point particulier : savoir expliquer quelque chose c'est montrer qu'on l'a compris. Je valide ainsi la maîtrise d'une notion, d'une connaissance nécessaire à la réalisation d'une tâche. Et si je n'ai pas les attendues, les informations, les mots que je veux, je complète. Je félicite sur ce qui a été dit et fait, je corrige, je complète et en disant et montrant ce que j'attendais en plus. J'enseigne, je partage.

Industrialiser

Pour le wiki, pour les scripts, pour le nommage des fichiers, pour toute action nous avons défini autant que faire ce peut des règles de nommage, d'écriture, la façon de faire les commentaires, de documenter... Nous avons donc une façon assez proche de travailler. Je n'ai alors pas besoin de réexpliquer ce que j'attends, le formalisme etc. il est déjà défini : gain de temps, la personne fait ce que j'attends comme je le veux, je suis content et confiant, la personne est en autonomie... Que du positif.

Un point d'équipe chaque matin et chaque soir

Chaque matin, nous commençons la journée par une réunion d'équipe, rapide. Nous décidons ensemble des tâches à réaliser, j'expose et partage ma vision des choses, définis les priorités.

Chaque soir, avant l'heure du départ, nous prenons 10 minutes et je pose inlassablement les mêmes questions :
qu'as tu appris aujourd'hui ?
quelles ont les difficultés que tu as rencontrées aujourd'hui ?
est-ce que ta journée t'a plu ?

Je prends connaissance des réponses et y prête attention. Souvent je fais remarque que nous avons vu plus de choses qu'ils ne le pensent... Je leur rappelle les notions apprises et abordées ce jour, les éléments que j'ai voulu et pu leur apprendre et qu'ils se sont appropriés...

La gestion des conflits

Les problèmes et conflits ne doivent pas être réglés en publique, devant tout le monde, mais dans une salle, à part, seul à seul. On commence par présenter les choses positives. Et ensuite on parle d'amélioration, des choses qui ne vont pas et qu'ensemble, on va pouvoir changer. On commence par parler des ses propres problèmes : difficultés à cerner la personne, à interagir avec elle. On doit apprendre à laisser l'autre répondre, l'écouter.

Il faut toujours garder son calme, ne jamais aller dans le conflit, ne pas hausser la voix. D'autant plus si on a une relation de hiérarchie...

Remise en question

Enfin, pour finir, chaque semaine, je remets en question ma façon de gérer mon équipe. J'essaie de faire le bilan de ce qui s'est bien passé, de ce qui a été source de tension voir de conflit. Et je cherche à les éviter, à palier aux risques que cela ne se reproduise. Cela passe par la discussion avec le collaborateur. Cf la gestion des conflits.

Nous sommes donc en amélioration continue, semaine après semaine, consolidant ce qui marche bien, améliorant ce qui peut et doit l'être.

Conclusion

J'espère que ce billet partageant mon expérience sera utile et inspirant. Il rejoint la longue liste des billets de blog de partage d'expérience que j'ai pu publier et que j'espère encore publier dans les prochaines semaines et prochains mois.

Après de l'importance d'être aidé Nouvel billet intimiste et personnel, qui fait un peu suite, cette fois sur le sujet de la cyclothymie.

La cyclothymie est un trouble de l'humeur dans le spectre de la bipolarité, au cours duquel les périodes euphoriques et les périodes dépressives et d'irritabilité se succèdent. (...)Symptômes : La cyclothymie se caractérise par un état mental où se succèdent des périodes euphoriques et des périodes de baisse d'humeur sans qu'il s'agisse de véritables épisodes maniaques ou dépressifs. L'humeur du cyclothymique passe facilement de la tristesse à la gaieté, de la joie à la colèreWikipedia

Après un été de silence et la publication d'un billet personnel, intimiste et de témoignage Retour après deux mois de silence où j'évoque assez longuement ma situation personnelle, voici un nouveau sujet explorant ma personnalité et mon caractère.

Avec les années, j'ai rédigé de nombreux billets qui expriment mon évolution personnelle, qui explorent celui que je suis, d'où je viens et où je vais. J'avais rédigé il y a quelques années un billet sur le "Mode Genma", parlant d'une malaise et du mal-être que je vivais, partagé entre ma vie quotidienne et celle du week-end. Il y a eu toute la réflexion sur mon pseudonymat, le passage du pseudonymat au pseudonyme, les diverses réflexions en découlant : puis-je encore faire ce type de billets personnels et intimistes ? Je pense qu'à travers une relecture de toutes ces réflexions, billets forme de thérapie personnelle en ligne, on pourra retrouver en trame de fond ma cyclothymie.

Le rythme des publications sur le blog n'est pas significatif et ne peut pas être un indicateur de ma cyclothymie (hormis dans des phases longues de non publication comme à l'été 2018, mais c'est là le signe d'une phase plus longue et profonde) car je prends des moments (des journées ou des week-entiers de temps en temps) pour écrire des billets divers et variés (la plupart technique), intemporel (non liés à l'actualité), dont je programme la publication en avance. Je profite donc de phases où ça va bien pour faire une réserve de billets de blog pour les phases où ça va moins bien...

Pour en revenir au sujet, il y a bien longtemps que j'ai compris que j'étais cyclothymique. Je ne saurai dire à quand cela remonte, à quand j'ai pu mettre un nom sur ce problème. Je sais juste que dans ma phase de Lifehacking extrême, où j'ai tracé au quart d'heure près tout ce que j'ai pu faire de mes journées des mois durant, j'ai aussi fait des tableaux de suivi divers et varié, et j'ai été jusqu'à noter mon humeur du jour, pour pouvoir suivre l'évolution et l'associer aux événements du jour. Indirectement, ça a été une forme de mesure des tendances de ma cyclothymie.

Etre cyclothymique ne doit pas être évident à vivre pour l'entourage car les proches ne comprennent pas que parfois on est bien, parfois on est pas bien et que non, "on ne fait pas la tête", ce n'est juste pas une bonne période.

Etre cyclothymique, c'est donc alterner des phases de passion, d'euphorie, avec des phases de déprime et parfois de dépression. Ces phases ne sont pas selon un rythme ou un cycle défini, ont des durées plus ou moins longues. Le manque de sommeil, les insomnies, la fatigue, sont plus des conséquences d'une mauvaise phase de la cyclothymie qu'une cause. Le fait de tout intellectualiser, d'essayer de rendre les rapports humains et les interactions avec l'autre plus facile, tout en gardant le contrôle, sont probablement étroitement liés à des moments où l'esprit finit par dire stop et avoir besoin de souffler, de décompresser.