PROJET AUTOBLOG


Le Blog de Genma

source: Le Blog de Genma

⇐ retour index

Le métier passion

jeudi 1 janvier 1970 à 01:00

Cela fait un petit moment que je n'ai pas écrit de billet sur mon emploi actuel. Les précédents billets, à savoir Mars 2017 : Je suis chef d'équipe ; tu nous rejoins ?, Mai 2017 : Où sont les passionné.e.s ? ou encore Septembre 2017 : Il y a un an - Ma lettre de motivation sont toujours aussi vrais. J'ai même fait une conférence sur le sujet de mon évolution personnel ( Du pseudonymat au pseudonyme) et de la relation particulière que j'ai avec ma hiérarchie du fait que mon pseudonyme soit connu.

Comme je le disais dans mon billet sur l'autocensure, le partage de son expérience et de ses erreurs est important pour éviter à d'autres de faire les mêmes, du moins de pouvoir apprendre de notre propre expérience. Voici donc un billet sur le métier passion et à quel point cela peut devenir problématique...

En un an, d'architecte à directeur d'équipe

Depuis que j'ai découvert Linux et le logiciel libre il y a plus de 15 ans, j'ai rêvé secrètement d'être payé pour ma passion. J'ai toujours été intéressé par le sujet mais je n'avais jamais eu l'occasion de travailler dans le domaine du logiciel libre. En août 2016, j'ai redéfini mes priorités et j'ai passé mes vacances d'été, soit 3 semaines au rythme à 8h par jour à apprendre à être administrateur système, à monter en compétence sur le sujet, à consolider des connaissances et une expérience de plusieurs années. En Octobre 2016, je posais ma démission. Et je commençais en janvier 2017 avec une mission en tant qu'architecte. J'ai débuté ma nouvelle carrière avec déjà une reconnaissance de mes compétences (le fait de passer de consultant confirmé à architecte). Et en étant déjà dans une phase où j'avais passé des vacances non pas à me reposer mais, d'une certaine façon, à travailler, du moins à faire fonctionner mon intellect des jours durant sans le moindre repos.

A la fin de mes vacances d'été 2017, je rédigeais Bilan de mes vacances d'été. J'y abordais le fait que durant les six premiers mois de mon nouvel emploi, j'avais cherché à trouver un rythme sans vraiment de succès, que la seconde partie de l'année, j'avais des projets plus personnels, qu'il y avait le fait que j'allais me déconnecter un peu le week-end.

Le constat est que cela a été le contraire... En semaine, je suis allé au-delà de ce que l'on attendait de moi. Je me suis impliqué dans différents projets parce que je le voulais, parce que cela me plaisait. On en m'a rien demandé, on ne m'a pas forcé. J'ai choisi. Cette implication au quotidien a donné lieu à de la véritable reconnaissance de la part de ma hiérarchie, en me donnant en début d'année 2018, plus de responsabilités que je voulais (Mon profil Linkedin parle pour moi et montre ma progression dans ma carrière et j'en tire un certain plaisir et satisfaction).

Le métier passion

Pourtant, j'ai du me rendre à l'évidence. Mon métier est devenu une passion dévorante. J'aime ce que je fais. Vraiment. Chaque jour je me lève content d'aller sur mon lieu de travail. Et le soucis et ce que je n'ai pas vu venir, c'est que ma conscience professionnelle va très probablement au delà de ce qu'elle devrait être, du fait de plusieurs choses.

J'ai vécu une première carrière au sein de la même grande entreprise informatique, dans laquelle je me suis investi et où je n'ai aucune reconnaissance. Manque d'expérience, manque de contact avec ma hiérarchie, manque d'implication. J'ai cherché à faire reconnaître mes connaissances acquises à titre personnel (veille, connaissances et applications dans le domaine du logiciel libre, blog...) sans succès (cf mes billets sur le sujet comme Outer mon hacktivisme ? et Du pseudonymat au pseudonyme), ce qui avait conduit à ma démission et à l'entrée dans ma nouvelle entreprise. Et là, c'est tout le contraire : je fais ce que j'aime, travaille avec des technologies que j'aime sur des sujets que j'aime...

Avant, dans mon ancienne carrière, je pensais savoir ce que je valais et je n'avais jamais eu l'occasion de montrer mes véritables compétences. Avec ma nouvelle carrière, je fais de mon mieux et encore plus je m'implique et la reconnaissance des autres et de ma hiérarchie est là. Et surtout je vois que j'ai regagné en confiance en moi, que mes compétences personnelles étaient bien réelles.

Je connais mes capacités, mais mal mes limites. Et je n'ai cessé de vouloir aller plus loin. J'ai commencé à arriver plus tôt. A partir plus tard. A avancer des sujets le week-end. Parce que j'en avais envie. Parce que ça me plaisait. Parce que le chantier de refonte et de consolidation du système d'information est un chantier de grande ampleur, technique, qui prend plusieurs mois et que j'ai envie d'avancer. Ça me plaît, ça m'intéresse....

Mais quand on commence à se réveiller la nuit et à prendre des notes pour se dire "Je dois faire ça, et si, et ça" et qu'on ajoute des éléments à sa todo-liste de sa journée, cela doit être un signe. Quand on commence à moins dormir, à avoir des insomnies... Non pas à cause de cauchemars, de mal-être ou autre. Mais tout simplement parce que le cerveau ne s'arrête pas. Il réfléchit, avance, se nourrit de la passion. Le déclic aurait dû être quand je, réveillé à 5h du matin, je me suis "de toute façon je ne dors plus, alors autant me lever, partir plus tôt et arriver plus tôt, ou commencer ma journée et partir à la même heure". La fatigue s'est accumulée insidieusement... Mais la stimulation des journées, les cafés, l'excitation et le plaisir de travailler. J'ai compté les heures faites en semaine.... Juste pour voir. Et j'ai tiré plaisir de ce chiffre élevé qui ferait bondir n'importe quel syndicaliste. A côté de ça, je me suis mis une pression personnelle, ai fixé mes propres objectifs et un niveau d'attente et d'exigence tel que je me suis retrouvé à me trouver déborder alors que je suis tellement organisé avec mon lifehacking, ce n'est pas possible... J'ai commencé à tout intellectualiser (le prochain billet sera plus particulièrement sur ce sujet).

A la fin de ma précédente carrière, j'étais en bore-out, sur une mission placard, avec peu d'activité et la déprime, le manque de confiance en moi, l'absence de reconnaissance... Avec mon métier actuel, j'ai donné sans compté, par choix, par plaisir, j'ai parfois fait des sacrifices volontaires sur mon temps personnel, mais comme j'avais et j'ai une réelle reconnaissance, j'ai frôlé le burn-out. Burn-out. Le mot est dit. Je suis passé d'un bore-out il y a un an et demi à un signe annonciateur de burn-out.

Avec des éléments personnels à côté compliqué dont je ne veux pas parler (cf mon billet Autocensure, nouvelle réflexion sur le sujet, j'ai dû prendre du recul. Ce que je fais via la rédaction de ce billet (et d'autres, écrire pour le blog me détend), en prenant du temps pour moi, à regarder des séries et des documentaires sur Netflix, en me changeant les idées et en pensant à autre chose... Je pense que ça ira mieux une fois que j'aurai repris un de ma fatigue cumulé et que j'aurai assimilé le fait que je suis avant tout un humain et non une machine.

En conclusion

Je le redis, j'aime mon métier. Vraiment. Ce n'est pas tous les jours faciles. Mais ça me plaît. Je fais enfin ce que j'aime et ce que, quelque part, j'ai toujours cherché à faire. J'ai enfin trouvé ma voie. Mais je vais travailler sur ma volonté de toujours en faire plus. Je peux en faire un peu plus, mais pas beaucoup plus. Je dois apprendre à compter mes heures, à savoir m'arrêter, à savoir remettre au lendemain ou à déléguer. Ainsi, je continuerai de m'épanouir, mais de façon positive.

Silence vs signal quelle combinaison ?

jeudi 1 janvier 1970 à 01:00

Attention : Silence est une application pour un échange de SMS chiffré. Signal envoie des Messages chiffrés (nécessité de connexion via un serveur), mais permet aussi l'envoi et la réception de SMS classique (passage par les services des opérateurs téléphoniques). Je précise donc bien SMS chiffré ou Message chiffré. Il existe un comparatif détaillé de pourquoi l'un ou l'autre de ces applications pour des échanges chiffrés et la réponse, en résumé est "Ca dépend". Pour le détail et le pourquoi ce Ca dépend, voir Support Signal vs Silence.

L'objectif ici est de savoir quelle est la combinaison pour avoir à la fois Silence et Signal sur son smartphone, ne pas avoir à choisir l'un ou l'autre mais pouvoir avoir les deux, pour être joignable via deux canaux de communications chiffrés différents, selon l'exposition / le modèle de menace lié à l'échange en cours (qui a la possibilité de voir les métadonnées de l'échange, voir Support Signal vs Silence).

Protocole de test

J'ai deux téléphones, un smartphone personnel et un smartphone professionnel. J'ai donc fait des tests pour déterminer qu'elle était la combinaison gagnante.

Sur le téléphone professionnel, j'ai mis Signal en application SMS par défaut et Silence en application secondaire. Sur le téléphone personnel j'ai mis Silence en application SMS par défaut et Signal en application secondaire.

Envoi de SMS normaux
Les téléphones les reçoivent en clair dans leurs applications SMS par défaut, et ce dans les deux sens (envoi pro vers perso et inversement).

Après activation des canaux de communication chiffré au sein de Silence et au sein de Signal (échanges des clefs entre les deux applications via les numéros des smartphones).

Envoi d'un SMS chiffré depuis Silence du perso vers le pro : le SMS chiffré arrive dans Signal (application par défaut de SMS) est cryptique / chiffré. En même temps, Silence notifie l'arrivée d'un message et permet de le lire de façon déchiffré.

Envoi d'un SMS chiffré depuis Silence du pro vers le perso : le SMS chiffré arrive dans l'application par défaut Silence et peut être lu. Signal pourrai ne pas être présent.

Envoi d'un message chiffré depuis Signal du perso vers le pro. Et envoi d'un message chiffré depuis Signal du pro vers le pro

L'application Signal n'est pas l'application SMS par défaut ne change rien. Dans tous les cas, l'envoi et la réception du message chiffré nécessite l'activation de la connexion data - d'une connexion à Internet (Wifi ou 3-4G). L'envoi ne peut se faire en chiffré que via une connexion au serveur de Signal, la réception nécessite une connexion Internet.

Tant que la connexion n'est pas active, on reçoit les SMS normaux dans Signal (si l'application est l'application SMS par défaut) et les messages chiffrés à l'activation d'une connexion à Internet.

Conclusion : la bonne combinaison ?

La bonne combinaison pour avoir Signal & Silence sur son smartphone est donc d'avoir Signal en application SMS par défaut et Silence en application secondaire. Il faut garder à l'esprit que pour recevoir des messages chiffrés au sein de Signal, il faut activer la data si on veut être joignable. Signal relèvera les SMS dans tous les cas (SMS classiques et SMS chiffrés), ceux qui sont chiffrés seront aussi lisibles dans Silence en clair.

Autocensure, nouvelle réflexion sur le sujet

jeudi 1 janvier 1970 à 01:00

Dans un précédent billet Réflexions sur l'autocensure, je me posais la question de ma propre censure du fait que mon pseudonymat était devenu un pseudonyme et donc connu de mon employeur et de ma hiérarchie qui lit certains billets de ce blog.

Ajouter à ça, il y a le fait que l'accumulation de billets de partages et de confessions personnelles m'avait valu un P.O.C. (Proof of Concept) démontrant qu'un doaxing serait préjudiciable (Lire Ménage sur ce blog).

Toutefois, comme je l'explique dans ma conférence Du pseudonymat au pseudonyme, ma propre évolution et le recul que je peux avoir sur elle, ce partage d'expérience, peut s'avérer utile à d'autres. Tout comme moi-même je m'enrichis du partage d'expérience d'autres (que ce partage soit technique ou humain), je pense que certaines personnes peuvent s'enrichir, se faire leur propre opinion, trouver des réponses à des questions qu'elles se posent au travers de mes propres billets de blog partageant mes réflexions.

Babozor de la Grotte du Barbu, au sein de ses différentes vidéos, que ce soit celle de la Grotte ou de Barbu Nawak, est dans cette démarche. Partager ce qui marche mais aussi ses erreurs, montrer ce qui ne va pas, quand ça ne va pas. Dire qu'on est dépressif, qu'on se sent seul en tant que père célibataire ayant une enfant entrant dans l'adolescence... Tous ces témoignages permettent à d'autres de s'enrichir, d'apprendre des erreurs, des doutes, des questionnements d'un autre...

Ce partage est pour moi important. Il y a le partage de mes connaissances techniques, mais aussi de mon expérience de vie... Avec le temps j'ai donc de nouveau réfléchi à cette problématique et ma véritable autocensure vient de moi-même. Je ne peux pas et je ne veux pas tout dire : il y a des choses dont j'aurai eu ou aurai besoin de parler mais dont je ne souhaite aucunement laisser une trace numérique (Les paroles s'envolent les écrits restent). Et il y a des choses que je peux assumer, que je veux partager. Et qu'importe que mon employeur le lise. Comme je le dis dans ma conférence, un blog est un espace d'expression personnel, je ne parle pas au nom de mon entreprise. Mon partage de mon expérience au sein de cette dernière est utile pour recruter de nouveaux collaborateurs...

De ce fait, dans les prochains jours, une fois finalisé, je publierai deux billes de réflexions personnels : Tout intellectualiser et Le travail passion TEASER. Ces deux billet seront étroitement liés à un partage d'expérience lié à mon travail au quotidien (le titre du second billet de blog est on ne peut plus explicite), leur publication et leur contenu montreront que non, je ne m'autocensure pas. En tout cas, pas pour tous les sujets ;)

Comment j ai fait du social engineering... inconsciemment

jeudi 1 janvier 1970 à 01:00

L'ingénierie sociale

L'ingénierie sociale ("social engineering") est une technique qui vise à accéder à des informations confidentielles ou à certains actifs par la manipulation de personnes qui y ont accès directement ou indirectement. Le « phishing » (hameçonage) est un exemple d'ingénierie sociale.

Je ne m'attarderai pas plus sur le concept, on trouve des tas d'informations sur le sujet et quand on est à minima sensibilisé à la sécurité en informatique, le concept d'ingénierie sociale est quelque chose que l'on connaît. Dans le présent billet je voudrais relater une aventure que j'ai eu dans laquelle j'ai, comme le dit le titre de ce billet de blog, fait du social engineering... inconsciemment.

Mon anecdote

Dans le cadre de mon travail, j'avais besoin d'un accès à une plateforme particulière. Fin de journée, journée difficile. La seule personne qui a le compte d'accès est partie et est dans les transports en commun. Je l'appelle. La personne estime que la création d'un compte pour moi peut attendre son arrivée chez elle d'ici une heure, quand elle aura accès à un ordinateur.

Journée difficile pour moi, j'ai un stress communicatif et je mets donc la personne en situation de stress. Elle insiste sur le fait que cela puisse attendre ; j'insiste sur l'urgence et la nécessité de pouvoir me connecter. Je demande son identifiant et mot de passe pour pouvoir me connecter et faire la manipulation de création de compte.... La personne a fini par m'envoyer dans l'urgence via un canal sécurisé (un sms via Silence avec action du chiffrement) son identifiant et mot de passe. J'ai pu accéder au site web, m'ajouter un compte administrateur (avec un mot de passe issu de Keepass).

Le lendemain, j'ai fait une sensibilisation à l'hygiène numérique au collaborateur. En effet, étant désormais en possession de son mot de passe, même si elle peut avoir confiance en moi, cette confiance doit rester relative. Je l'ai donc inviter à changer son mot de passe et surtout à vérifier que le mot de passe donné était utilisé uniquement pour ce compte là et non un mot de passe générique que la personne utiliserait partout / pour tous ses comptes (règle d'hygiène numérique de base : avoir un coffre-fort numérique de mot de passe comme Keepaas).

En quoi est-ce de l'ingénierie sociale ? Et ce qu'il faut retenir de tout ça

Dans mon cas, le stress communicatif a fait que j'ai obtenu le mot de passe. Je ne l'ai pas fait volontairement, mais j'ai agi en utilisant une technique bien connue de l'ingénierie sociale : mettre la personne en situation de stress, avoir un ton direct et autoritaire, jouer sur l'autorité, l'urgence. Trouver le levier qui fait que la personne cède. On peut aller loin juste en parole : "tu ne veux pas que j'appelle ton supérieur qui alors va te faire des remontrances..." par exemple.

Cette expérience montre donc qu'il est très simple de faire de l'ingénierie sociale. Dans mon cas la personne me connaissait et j'avais une relation de hiérarchie indirecte sur elle. Mais si cela avait été un attaquant, sûr de lui, sachant pertinemment ce qu'il faisait avec un collaborateur ayant accès à des données plus sensibles ?

Nous avons eu une formation de sensibilisation à la sécurité. Je prévois de moi-même en faire d'autres. Nous avons et nous continuons sans cesse (dans le cadre de l'amélioration continue) améliorer notre politique de gestions des comptes et des mots de passe (je dois faire un billet dédié sur le sujet).

Mais on constate que malgré tout ça, il reste encore des services qui ont un seul accès maître détenu par une seule personne, ce qui est un point de fragilité, comme le montre mon histoire (quid d'une personne en congés etc...). Et que l'on a beau mettre en place toutes les mesures de sécurité que l'on veut, la faille de l'humain reste encore la plus facile à exploiter...

Il faut dès que possible favoriser une double authentification car dès lors que l'on a un identifiant et un mot de passe

Lifehacking - Gitlab, outil idéal ?

jeudi 1 janvier 1970 à 01:00

Depuis quelques années, je suis adepte du lifehacking et nombreux sont les articles que j'ai écrit sur le sujet. Des Todo j'en ai fait des tas, sur toutes les formes...Je suis familier de toutes les techniques organisationnelles projets comme les RIDA, RACI et autres... J'avais essayé de trouver un formalisme sous forme de tableau pour avoir un suivi des tâches, au sein de nombreuses itérations. Avec de nombreuses colonnes : projet, acteur, date de début, de fin, échéance, priorité, remarques... Mais quelque soit la mise en forme, la façon de faire (un onglet par projet ou autre), cela était toujours aussi peu flexible.

Gitlab

Au sein de mon entreprise, comme nous faisons du développement logiciel, nous avons une instance Gitlab auto-hébergée de la version communautaire. Parmi les fonctionnalités de Gitlab, au delà de l'aspect forge logicielle / hébergement de code, il y a différentes fonctionnalité que nous utilisons de plus en plus et ce pour chaque projet, dans le cadre de notre industrialisation. Dans le présent billet, je voudrais donc faire un retour d'expérience des différents outils.

Le Kanban

Le Kanban est probablement l'outil que j'utilise le plus. J'avais déjà fait des Kanban sur base de post-it dans une mission en AGIL dans une vie antérieure, j'avais un mur chez moi pour la gestion des mes projets personnels avec des post-it de différentes couleurs... Mais cela n'est pas pratique pour un partage, pour un travail à plusieurs et n'a pas de solution pour un usage en mobilité...

Les locaux actuels sont vitrés, les équipes avec lesquelles je travaille sont réparties au sein de différents services... J'ai besoin d'avoir une vision sur les différents projets et de pouvoir la partager.

La solution a donc été la généralisation de la mise en place d'un projet par service avec l'activation du Kanban pour chacun de ces projets. Et un Kanban pour les sous-projets. Je travaille encore avec une todo-liste que j'ai dans un bloc de papier dans lequel je note ma liste de choses à faire, que je raye au fur et à mesure de la journée. Toute tâche qui nécessite plus de détail, de suivi, d'être déléguée est si besoin rayée de la liste et mise dans le Kanban.

Avec le Kanban, j'ai un suivi des actions sur plusieurs jours ou plusieurs semaines, je suis sûr de ne rien oublier. En un ticket, j'ai un numéro de suivi si besoin, un acteur, je peux ajouter des dates. Et sur le ticket, je peux faire un suivi, commenter, ajouter des précisions, des liens vers le wiki et faire vivre l'action. Comme tout est électronique et au sein d'un navigateur web, c'est accessible, partageable. Les commentaires et le suivi sur un ticket sont cachés par défaut mais permettent d'avoir un suivi, de copier coller des échanges par mail, de mettre des liens vers d'autres tickets, des documents, des pages wiki... J'ai l'état d'avancement. Chacun peut commenter le ticket, ajoute des liens vers les pages wiki en cours de rédaction. On sait qui a quelle tâche. On voit l évolution. Il est possible de taguer un fichier avec plusieurs mots clefs chacun associés à une couleur. Il est possible pour chaque ticket de définir des dates de fin, un nombre de jours de réalisation, un "milletsone".

Dans les conseils que je donnerai il y a celui de prêter attention au nom des tickets qui doivent être autoporteur. Il ne doit pas être nécessaire d'ouvrir le fil du discussion du ticket mais il ne faut pas trop détailler non plus dans le titre. Un équilibre se trouve assez facilement au final.

Bref, j'ai trouvé dans le Kanban de Gitlab tout ce que j'avais cherché en essayant de structurer mes suivis d'action dans des fichiers avec colonnes...

En Kanban, j'avais auparavant testé l'usage de celui de Nextcloud (Deck) et celui de Kanboard. Mais celui de Gitlab, au delà de son intégration dans l'écosystème Gitlab, a de suite eu mon adhésion définitive. Un design plus moderne, plus riche, intégré avec tout un écosystème d'outils complet que je présente dans la suite de ce billet.

Le wiki

Pour chaque projet, Gitlab permet de créer un wiki dédié au projet. Chaque page est une page texte au format Markdown, qu'il est possible d'éditer au sein du navigateur même (avec une fonction de prévisualisation). Les fichiers étant des fichiers textes, ils sont suivis dans une branche dédiée par Git, avec toute la puissance niveau historisation que cela peut avoir.

Le wiki est récupérable en local en tant que projet Git, la bonne pratique est donc que chacun clone le wiki comme projet en local. Il n'y a pas de fork d'implémenter au sein même de Gitlab, on ne peut donc pas faire des forks et ensuite des branches etc. Tout le monde travaille donc sur un même dépôt qu'est le wiki ; cela nécessite donc de s'astreindre à certaines règles : mise à jour régulière du serveur vers le local et ce avant toute modification. Remontée rapidement sur le serveur les ajouts fait au wiki localement.

Pour l'édition, comme je le disais, le format est le format Markdown. On peut éditer au sein de l'interface web ou en local. C'est et ça reste du fichier texte. Nous avons mis en place un tutoriel utilisant l'éditeur Atom qui permet l'édition et la prévisualisation du Markdown (pratique pour avoir du WYSIYG) et un plugin Git pour pousser les modifications depuis Atom sur le serveur. Cela facilite la vie pour l'édition du wiki. Je pense que mettrai ce tutoriel en ligne sur ce blog pour le rendre accessible à tous.

La wikification : ce que j'appelle wikification c'est le fait de tracer dans le wiki toute information pertinente qu'il est nécessaire de garder, de conserver, au sein d'une base de connaissances. Nous généralisons, traçons, mettons à jour les procédures, les astuces etc. Tout ce que l'on peut attendre d'un wiki, nous le faisons au sein des wikis des différents projets de Gitlab.

Nous sommes d'ailleurs en train de reverser peu à peu les informations pertinentes en les mettant à jour d'un ancien wiki qui était sous Media Wiki dans le nouveau wiki. Un chantier long et fastidieux, mais nécessaire. L'ancien wiki était peu pratique, devenu lourd avec le temps, rédigé par des générations successives de collaborateurs sans suivi d'un formalisme particulier. Repartir sur une base saine et souvent le mieux à faire et nous le faisons.

L'espace fichier

Initialement prévu pour stocker du code source, nous utilisons cet espace pour stocker une arborescence définie de fichier. Avant il y avait un Intranet mais un simple partage de fichiers (nous n'avons pas de GED), mais avec le temps et l'accumulation des fichiers, c'est un peu devenu un fourre-tout inutilisable et inexploitable.

Nous utilisons donc pour chaque nouveau projet l'espace de fichier pour y stocker les fichiers de travail (fichier de configuration, documentation, procédures) dont nous avons besoin d'avoir une historisation, une centralisation et qui ne sont pas wikifiables.

Dans les pistes en cours d'étude il y a le fait que nous cherchons à pouvoir convertir des notes saisies en Markdown en documentation livrable au client, dans un format LibreOffice Writer avec un template de fichier défini (avec des codes couleurs précis). Un projet comme Pandoc pour la conversion avec ensuite application d'une feuille de style particulière sera à creuser.

Organisation des projets

Un service donne lieu à un projet, un projet donne lieu à un projet en lui-même dans Gitlab. Les pages wiki et la documentation sont mises au sein du projet pour lequel c'est le plus pertinent. Dans les autres wikis des autres projets, des liens sont fait vers les pages wiki et documentation de références. On utilise ainsi la puissance du web.

Pour faire un suivi à la hiérarchie, lors des réunions hebdomadaires, il suffit de présenter deux planches : une capture d'écran du Kanban prise en semaine N-1 et un une capture du Kanban de la semaine en cours. On peut alors visuellement voir l'avancement avec les tickets déplacés, les tickets en cours...

Bref, Gitlab est devenu un outil incontournable, efficace et indispensable pour moi.

Non intuitif pour les non informaticien.ne.s

Comme nous industrialisons nos projets, tout nouveau projet quel-qu'il soit est désormais créé dans Gitlab. Et le constat a été fait rapidement que dès que l'on sort d'une population purement d'informaticien, Gitlab nécessité des améliorations de son interface graphique pour pouvoir permettre une appropriation de l'outil en particulier dans la partie gestion des fichiers et suivi des modifications, qui restent avant tout pensé comme du "diff de code".

Et je ne suis pas seul à avoir saisi à la fois la puissance de Gitlab et le fait que ce n'est pas adapté aux non-informaticien.ne.s. En effet, dans le cadre de sa campagne Contributopia de Framasoft, dans la partie "Éducation populaire - Inspirer les possibles", il y a un projet Git à la portée de tou·te·s dont la description est la suivante : Git est un outil qui permet de collaborer collectivement sur du code. La manière dont il a été conçu ouvre une magnifique porte d'entrée vers les méthodes, pratiques et états d'esprits de la contribution. Comment faire pour que les personnes qui ne codent pas puissent profiter de la philosophie d'un tel outil ? Comment adapter git, son jargon, son interface, etc. afin que tout le monde puisse co-construire et collaborer sur des textes ou d'autres communs contributifs ? Des projets existent et c'est avec eux que Framasoft désire étudier des solutions.

Conclusion(s)

Au bout de quelques jours, Gitlab est devenu comme une révélation, un peu comme si je venais de trouver l'outil miracle. Nombreux sont les avantages que j'ai trouvé (me demandant même comment je faisais avant). Dans les autres avantages à avoir toute ma gestion au sein d'un même outil c'est que c'est pratique pour faire les sauvegardes.

Dans les autres petites choses que j'aimerai avoir et sur lesquelles il faut que je me penche, il y a celles d'avoir des métriques ou des statistiques en utilisant le temps de réalisation des tickets. Ce sera sûrement le sujet d'un autre billet, quand j'aurai pris le temps de me pencher sur ce sujet. Hop, c'est ajouté au backlog dans le kanban.