Le biais du survivant est une tendance à se concentrer uniquement sur les exemples qui ont survécu à un événement, en ignorant ceux qui ont échoué. En matière de cybersécurité, cela signifie que les entreprises ont souvent tendance à se baser uniquement sur les incidents de sécurité passés qui ont été résolus, sans prendre en compte ceux qui ont échappé à leur détection ou n'ont pas été correctement résolus.

L'un des exemples les plus connus est celui des avions durant la seconde guerre mondiale:

En étudiant les dommages causés à des aéronefs revenus de mission, l'étude a recommandé de blinder les endroits des appareils qui présentaient le moins de dommages. En effet, Wald a constaté que les études précédentes ne tenaient compte que des aéronefs qui avaient « survécu » à leur mission, sans tenir compte de ceux qui avaient disparu. Ainsi, les endroits endommagés des aéronefs revenus représentent les endroits où ces derniers peuvent encaisser des dommages et réussir à rentrer à la base.

Source : Wikipedia

L'idée est donc de dire que les incidents que l'on voit ne sont pas forcément les plus importants, et qu'il peut être pertinent de se focaliser sur ce que l'on ne voit pas.

Les limites de l'apprentissage à partir des incidents passés

Apprendre de ses erreurs est sans doute l'étape la plus importante d'un incident, qu'il soit lié à la sécurité ou non. Durant l'étape du post-mortem, le focus est souvent mis sur la raison de l'incident, et comment éviter sa reproduction et le monitorer.

Toutefois, les attaques et les menaces évoluent constamment, de nouvelles vulnérabilités sont découvertes et les attaquants utilisent des tactiques de plus en plus sophistiquées. Se baser uniquement sur les incidents passés peut donc conduire à des lacunes dans la préparation à de nouvelles menaces.

Par exemple, une entreprise peut se concentrer uniquement sur les types d'attaques qui ont été précédemment détectées et résolues, tandis que de nouvelles méthodes d'attaque peuvent être utilisées sans être détectées. Cela peut entraîner une fausse confiance en matière de sécurité, car les attaquants peuvent exploiter les vulnérabilités non prises en compte pour causer des dommages importants.

Détecter des attaques est une étape cruciale de la surveillance d'un système d'information, toutefois, il est aussi très important de garder en tête qu'il y a toujours la possibilité de vulnérabilité qui n'ont pas encore été identifiée.

On se rappellera par exemple de WannaCry en 2017. Le ver était resté en sommeil pendant une longue période avant de s'activer et verrouiller énormément de systèmes, provoquant même l'arrêt de certaines entreprises.

WannaCry ransomware attack - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

En se basant uniquement sur les incidents visibles, de nombreuses entreprises ont donc été durement impacté par cette attaques.

La proactivité : l'arme de la cybersécurité

Il est essentiel d'adopter une approche proactive en matière de cybersécurité, plutôt que de simplement se fier aux incidents passés pour prendre des décisions. Cela peut inclure la surveillance continue des réseaux, la détection proactive des menaces, la formation des employés à la sensibilisation à la sécurité, ainsi que la mise en œuvre de mesures de sécurité appropriées pour protéger les systèmes et les données.

Une approche proactive implique également de reconnaître les limites de l'apprentissage à partir des incidents passés et de ne pas se fier uniquement à cette approche pour évaluer les risques de cybersécurité. Il est important de rester informé des nouvelles menaces, de mettre à jour régulièrement les systèmes et les logiciels, de réaliser des évaluations de sécurité régulières et de former continuellement les employés sur les meilleures pratiques en matière de sécurité.

La cybersécurité est une veille continue qui doit permettre de rester en permanence au courant des dernières attaques, des derniers vecteurs, des dernières vulnérabilités. Regarder uniquement le passé n'est pas (ou plus) suffisant, il faut être en mesure de préparer les futures attaques, identifier les failles avant qu'elles soient activement exploitées, surveiller, monitorer.

J'en avais parlé dans le passé, mais l'arme principale d'un hacker est sa capacité à identifier rapidement des failles, mais aussi à penser différemment, à exploiter ce qui peut passer pour des détails.

Il est aussi important d'être au courant des derniers modèle d'attaques, il existe pour ca de nombreux site et flux RSS.

En France, nous avons notamment le CERT-FR, qui publie nombre de bulletin de sécurité avec énormément d'informations pertinentes.

CERT-FR – Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques

cert-fr Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

A noter qu'il existe aussi un flux RSS intégrable facilement sur des outils comme Slack par exemple.

Le site de l'ANSSI regorge aussi d'information utiles sur les bonnes pratiques pour prévenir autant que possible les incidents de sécurité.

Enfin, un détail souvent oublié : il est crucial de former ses effectifs, surtout les équipes techniques (Développeurs, Ops, etc.) afin qu'ils soient conscient des risques liés à la sécurité et puissent les prendre en compte dans leurs réalisations.

Pour terminer

Le biais du survivant peut être un piège dans le domaine de la cybersécurité, car il peut amener les entreprise à se baser uniquement sur les incidents passés résolus, en ignorant les menaces potentielles persistantes. Il est essentiel de reconnaître les limites de l'apprentissage à partir des incidents passés et d'adopter une approche proactive pour protéger les systèmes et les données.

Il est important de rester informé des nouvelles menaces, de mettre en place des mesures de sécurité appropriées et de former continuellement les employés à la sécurité. La cybersécurité est un processus continu qui nécessite une vigilance constante pour protéger les actifs numériques d'une entreprise. En adoptant une approche proactive, elles peuvent ainsi mieux se préparer aux nouvelles menaces et réduire les risques de cyberattaques.

Oui, je sais, j'arrive après la bataille sur ChatGPT!

Pour une raison simple, j'aime me faire un avis et ne pas suivre aveuglément les modes dans la Tech, surtout que lesdites modes ont tendance à passer bien vite, on se rappelle (ou pas) de nua.ge qui a fait un grand coup de com' à coup de vouchers chez des "influenceurs" et a disparu des ondes aussi vite qu'il est apparu.

Bref, revenons à nos moutons! ChatGPT va remplacer les métiers de l'IT, c'est ce que j'ai lu pas mal de fois ces derniers temps, disant que nous serons relégués à de simples exécutants de requêtes sur ChatGPT.

Bon, qu'on se le dise, on a encore un peu de temps devant nous, mais nous allons voir tout ça en détail.

ChatGPT, c'est quoi ?

Commençons par les bases, ChatGPT est le dernier-né de l'entreprise OpenAI. L'objectif de cette entreprise est de promouvoir l'intelligence artificielle en l'"humanisant" autant que possible.

Les usages de l'intelligence artificielle au quotidien pourraient améliorer le quotidien de beaucoup d'utilisateurs.

Attention, on parle bien d'un modèle d'IA, de l'IA tout court, ça fait trèèèèèès longtemps qu'on en voit en informatique, de simples "if" sont déjà une forme d'intelligence, aussi basique soit-elle.

ChatGPT est donc le dernier jouet d'OpenAI, ce dernier est un modèle de conversation textuelle humain. C'est-à-dire qu'il est capable de comprendre ce qu'on lui dit, mais aussi de répondre de manière "naturelle", comme le ferait un être humain.

Il s'agit donc avant tout d'un modèle entrainé pour comprendre les demandes et répondre de manière cohérente. ChatGPT ne "sait" rien, il compile des informations qu'il a obtenues de multiples sources publiques.

Cela signifie aussi que cette IA a les mêmes biais que les humains. Il y a quelques années, c'était Amazon qui en avait fait les frais, avec son IA d'aide au recrutement sexiste et raciste... parce qu'elle était entrainée par les comportements des recruteurs d'Amazon!

Un article très complet en parle d'ailleurs ici (en anglais) :

Amazon’s sexist AI recruiting tool: how did it go so wrong?

Machine learning projects are hard. “Biased data” is only one element

Becoming Human: Artificial Intelligence MagazineJulien Lauret

ChatGPT sait coder, plus besoin de développeurs!

Est-ce que ChatGPT sait produire du code? Oui.

Maintenant, est-ce que ce code est utilisable et fiable à 100% out of the box? C'est un sujet plus compliqué.

Ce qui fait la valeur d'un développeur en entreprise n'est pas forcément sa capacité à délivrer beaucoup de code, ou à connaitre par cœur toutes les documentations, c'est sa capacité à s'adapter et à délivrer ce qui est attendu par son entreprise.

Cette capacité à raisonner et chercher la solution la plus adaptée n'est pas forcément innée chez ChatGPT.

Cela signifie par exemple que le code de base possède souvent de nombreuses duplications par exemple (peu de factorisation de code par défaut), il peut parfois être inutilement complexe pour un besoin simple aussi.

De même, étant donné que le modèle a été entrainé via des données publiques, toutes les données ne se valent pas. Je ne pense pas que ce soit une surprise si je dis que l'ensemble des données trouvées sur Internet ne sont pas de la même qualité.

Pour ma part, j'ai fait quelques tests simples avec l'outil, et quand des tests simples ont produit du code correct, dès lors qu'on commence à demander des spécificités, ChatGPT s'emmêle les pinceaux et arrive parfois à des contradictions dans ses réponses.

Une fois de plus, l'œil critique humain est nécessaire pour évaluer la qualité des réponses.

ChatGPT : Un outil parmi d'autres

Est-ce que je dois croire aveuglément ce que me remonte un SIEM, ce qu'une analyse de code statique me donne ?

La réponse est bien sûr non. En ce qui concerne ChatGPT, c'est la même chose, il s'agit d'un outil avant tout.

Est-ce qu'il permet d'aider à délivrer du contenu : oui, dans certaines conditions, mais comme tous les outils, il a ses limites, dont certaines que j'ai décrites plus haut.

En tant que tel, il faut le considérer comme un outil qui peut accélérer potentiellement les choses, mais en restant critique sur ses réponses, tout comme vous le seriez avec un quelconque parseur.

Si le résultat peut parfois être bluffant, cela reste un algorithme, raisonnant sur un modèle connu et limité. Le but premier de ChatGPT n'est pas le code, mais la discussion naturelle, et c'est sur ce domaine qu'il est plutôt bon.

Ainsi, pour obtenir des résultats précis, il faut parfois guider l'IA pour qu'elle produise ce qu'on veut, voici un petit exemple que je me suis amusé à faire

De plus, je reste dubitatif sur certaines réponses, si le modèle est indiqué comme "coupé d'Internet à la fin 2021", il semble avoir reçu des mises à jour "manuelles", comme ici, où il parvient à m'indiquer qu'Elon Musk est le PDG de Twitter, alors qu'il ne l'est que depuis octobre 2022.

On notera d'ailleurs que ChatGPT botte en touche quand on insiste sur la source de ses données.

En conclusion : ne mettez pas encore à jour votre CV

Je pense que vous l'avez compris, je pense que ChatGPT est un bon outil, qui est assez bluffant, mais je suis encore confiant sur le fait que nos métiers (dans l'IT) vont perdurer encore un moment.

Actuellement, ce modèle d'IA est limité sur beaucoup d'aspects, et surtout donne toujours raison à l'humain, même quand il a tort! J'ai ainsi réussi à faire dire à ChatGPT que 2+2 faisait 5 en lui disant qu'il avait tort en me répondant 4.

À noter que ChatGPT est basé sur GPT3, et que GPT4 est en cours de développement, promettant des possibilités énormément plus grandes!

L'amélioration de l'intelligence va bien entendu modifier notre manière de travailler, mais pour l'instant, j'imagine mal une entreprise pouvant se passer entièrement d'équipes en les remplaçant par GPT. Peut-être que l'avenir me donnera tort, mais je suis plutôt confiant.

Depuis quelques jours, suite au rachat de Twitter par Elon Musk, on entend beaucoup parler de Mastodon.
Certains se disent prêts à migrer de Twitter vers Mastodon, si nombre de billets de blog parlent de Mastodon vs Twitter du point de vue fonctionnel, on parle assez peu des aspects liés à la sécurité.
Ici, je ne vous parlerais pas de modération, de changements d'habitude, etc. simplement de mon point de vue lié à la sécurité.

Mastodon : comprendre le modèle décentralisé

Au contraire de Twitter, Mastodon utilise un modèle décentralisé.

Ce dernier permet d'avoir de multiples instances qui communiquent entre elles via un protocole commun.

Cela permet de ne pas nécessiter que l'ensemble des utilisateurs soit sur la même instance pour se suivre, réagir ou liker des "pouets" (l'équivalent des tweets).

Pour en savoir plus sur le sujet, je vous conseille l'excellent article sur le blog de Framasoft :

Mastodon, le réseau social libre qui est en train de bousculer twitter

Une alternative à Twitter, libre et décentralisée, est en train de connaître un succès aussi spontané que jubilatoire... Depuis que Twitter a changé la manière dont les réponses et conversations s’affichent, des utilisatrices et utilisateurs abondent par milliers sur cet autre réseau. Chacun·e cherc…

FramablogFramasoft

Et si on parlait de sécurité ?

Le souci du tiers de confiance

Vous l'aurez compris, nous avons déjà un premier "point faible", du a un principe que j'ai déjà abordé dans d'autres billets dans le passé : le tiers de confiance.

L'un des principaux défauts de Mastodon est aussi sa force. La décentralisation empêche une politique de sécurité commune à l'ensemble des instances.
Cela signifie donc que l'on confie des données potentiellement confidentielles et/ou sensibles à un tiers.
Tout dépend de l'importance que l'on attache aux dites informations, mais par exemple votre adresse mail peut potentiellement être exploitée par un administrateur malveillant ou une instance compromise.
Cela signifie aussi que d'une instance à l'autre, vous pouvez avoir différents niveaux de gestions de données sensibles.
Pour certains, il sera impossible aux modérateurs d'accéder aux données "personnelles", pour d'autres, ça sera open bar.

Modification du code

J'ai vu en boucle "Mastodon est open source, tu n'as qu'à voir le code si tu veux voir [choisir la feature sécurité]".
Oui et non, tout comme VSCode n'est pas l'exact contenu du repository open source, ce n'est pas parce qu'un système est basé sur de l'open source qu'il est déployé tel quel.
Au contraire, vu que le code est ouvert, il est d'autant plus facile pour quelqu'un de malveillant de le modifier pour en faire ce qu'il veut.
Ainsi, rien ne m'empêche techniquement de modifier le code de mastodon pour qu'il stocke les mots de passe en clair, m'envoie une copie de tous les MP par mails ou envoyer des messages en me faisant passer pour quelqu'un d'autre.

Phishing

Le côté décentralisé facilite aussi un autre aspect : le phishing.
En effet, étant donné qu'il n'y a pas de domaine prédéfini, rien ne m'empêche de mettre une page de création de comptes "fake".
Ainsi je peux récupérer pas mal d'informations sensibles, notamment les mots de passe.
En effet, si dans l'IT, nous sommes plus sensibilisés que d'autres sur la réutilisation de mot de passe, ce n'est pas le cas d'une grande partie de la population qui recycle ses mots de passe d'application en application.

De cette manière, je peux facilement tester un mot de passe que j'ai récupéré sur d'autres sites web pour en prendre le contrôle ou exfiltrer nombre d'informations.

L'infrastructure et le patching

Une fois de plus, étant donné que la solution est hébergée par un tiers, il est nécessaire de s'assurer que l'infrastructure qui héberge la solution est assez sécurisée.
En effet, la moindre brique non sécurisée est un vecteur d'attaque.
Tous les jours des dizaines de CVE (Common Vulnerabilities and Exposures) sont trouvées des produits, y compris des failles zéro day (faille inconnue non patchées), il est donc nécessaire d'avoir une veille de la part de l'hébergeur pour mettre à jour rapidement ses briques à chaque faille découverte, ainsi qu'une surveillance sur son infrastructure pour être à même de détecter et réagir à tout comportement anormal ou inhabituel.

Et twitter dans tout ça ?

On pourrait croire que je vais dire que Twitter est sécurisé, mais c'est faux.
Dans le passé, il y a eu de multiples hacks de Twitter, j'avais même parlé du dernier dans un billet sur ce blog.

Ce que nous apprend (ou rappelle) le hack de Twitter

Il y a quelques jours, Twitter a été la cible d’un hack invitant, via des “comptes vérifiés”, les utilisateurs à envoyer des BitCoins pour en recevoir le double. Je vous propose un petit post sur ce que nous pouvons retenir de cette attaque, du point de vue sécurité informatique. Disclaimer

TFerdinand.netTeddy FERDINAND

Toutefois, des mécanismes de protection dus au fonctionnement même d'une entreprise assurent un niveau de sécurité plus élevé, qui est potentiellement audité.
Twitter doit se conformer à de nombreux impératifs de sécurité de par sa taille et le fait qu'elle doit rassurer son public.

Ça reste tout de même une boite noire sur laquelle, de mon côté, je ne peux pas vous assurer que tout est à 100% sécurisé.

En conclusion : on oublie Mastodon ?

On pourrait croire que je dise qu'il faut donc s'enfuir loin de Mastodon avec ce que je viens de dire, mais c'est faux!
Comme à chaque fois que vous confiez vos données personnelles, il est important d'être conscient de la sécurisation de celles-ci.

Mastodon reste un outil open source très puissant qui dans certains modèles peut rivaliser avec Twitter.

Toutefois, son côté décentralisé le place aussi potentiellement en position de faiblesse quand on s'attarde sur la sécurité.

N'hésitez pas à réagir dans les commentaires pour donner votre avis!

Ça y est, vous êtes décidé! Vous allez démarrer blog!

Bon, maintenant, la vraie question : par où je commence ?

Pas d'inquiétude, je vais vous donner quelques astuces que j'ai apprises en presque 3 ans de blogging.

Pourquoi je peux en parler ?

Il y a 3 ans de cela, je publiais mon premier billet sur ce blog, après des mois et des mois d'hésitations.

Content d'avoir eu mes 10 premiers lecteurs (des amis et collègues de travail), j'ai continué à publier, en améliorant petit à petit mon contenu.

Aujourd'hui, vous êtes entre 3.000 et 10.000 visiteurs uniques à visiter ce site chaque semaine (en fonction du contenu que j'ai publié).

Je sais que j'ai un nombre conséquent de gens qui suivent ce blog, et mon flux RSS est dans l'abonnement de nombre de personnes!

Toutefois, cette croissance ne s'est pas faite par magie, et je vais vous expliquer les points clés qui m'ont permis de croitre et vous permettrons vous aussi de lancer votre blog avec succès.

Pourquoi écrire?

Cette question, c'est la première que vous devez vous poser : pourquoi voulez-vous écrire?

• Pour partager au plus grand nombre
• Pour être visible
• Juste pour vous
• Pour vous faire un porte-folio

Qu'on se le dise : il n'y a pas de mauvaise raison. Par contre, en fonction de votre objectif, vous n'allez pas aborder les choses de la même manière.

Pour ma part, j'écris pour partager au plus grand nombre, ce qui, par ricochet, implique le second point : pour partager à beaucoup de monde, il faut être visible!

Les deux derniers points sont les plus simples : ils ne vous engagent pas vraiment dans un rythme ou un niveau de contenu.

Pourquoi est-ce qu'on viendrait sur mon blog ?

Si votre but c'est d'être lu, il faut que les gens aient eu une raison de venir sur votre blog plutôt que celui d'un autre.

Pour ce faire, il existe plusieurs points.

Publier du contenu "atypique"

Ne pas suivre la masse vous permet de sortir du lot. Petit exemple en date : la faille log4j en décembre dernier.

Lorsque beaucoup de site et blog ont décidé de couvrir la faille en elle-même, et de la décortiquer 8.500 fois, j'ai préféré pour ma part parler de la réalité du terrain en tant que membre d'une équipe sécurité.

Avoir une approche nouvelle sur un sujet existant est rafraichissant à lire, je suis le premier à préférer lire ce type de contenu qu'un énième redit de la même chose.

Avoir du contenu atypique, c'est parfois aussi le choix de la langue. Ce blog est publié principalement en français (même si une version anglaise existe), cela me permet aussi de sortir du lot, vu que nombre de personnes n'aiment pas forcément lire l'anglais.

Offrir VOTRE point de vue

Personnellement, lorsque je vais sur un blog, c'est pour lire le contenu d'un auteur. Je ne veux pas forcément lire quelque chose de trop neutre.

Au travers des billets, c'est aussi l'occasion de vous exprimer, aussi bien sur le contenu que sur la manière de le présenter.

N'hésitez pas à mettre votre "patte"!

Publier du contenu régulièrement

Autre règle de base pour augmenter sa visibilité : la régularité.

Publier à intervalle régulier (pas forcément rapproché) va permettre de fidéliser votre lectorat en créant un "rendez-vous".

Attention toutefois, le but n'est pas de noyer votre lecteur sous le contenu, donc n'essayez pas de publier souvent, mais simplement avec des écarts fixes, par exemple une fois toutes les deux semaines.

Vous ne verrez pas d'augmentation de votre audience instantanément, mais sur la durée, ça paie!

Utiliser les réseaux sociaux

Les réseaux sociaux sont un bon levier pour parler de vos contenus.

Attention toutefois à cibler les réseaux qui sont exploités par votre lectorat, pour ma part, je me focalise principalement sur Twitter et LinkedIn qui contiennent le plus gros de mes lecteurs (environ 50% de mes lecteurs viennent de Twitter par exemple).

Mais attention, les réseaux sociaux, c'est aussi :

• Les réseaux décentralisés, comme Mastodon par exemple
• Les agrégateurs de lien, comme le journal du hacker

Ne négligez pas le levier que vous offrent ces sites, surtout si vous souhaitez construire une communauté à terme!

Mes conseils

Ne pas se focaliser sur les chiffres

Ce premier conseil est le plus important de tous!

Ne vous focalisez pas sur les chiffres, d'autant plus que lorsque vous démarrez votre blog, ces derniers risquent plus de vous démotiver.

Pour ma part, je regarde mes stats environ une fois par mois, afin de juste voir ma tendance.

Faire du trekking éthiquement

Vous pouvez faire du trekking pour comprendre d'où viennent vos lecteurs, vos articles les plus lus, etc.

Mais le plus important est de le faire en respectant vos lecteurs.

Par exemple, il est possible d'exploiter Matomo en lisant juste vos logs applicatifs.

J'ai publié dans le passé un petit billet qui en parle :

De l’audimetrie de Traefik libre avec Matomo

Il y a quelque temps, je vous avais parlé du tracking et des raisons pour lesquelles je tenais à ma vie privée[https://tferdinand.net/pourquoi-est-ce-que-je-tiens-a-mes-donnees-personnelles/]. Dansma conclusion, j’indiquais que le tracking utilisateur restait tout de même unoutil utile pour une…

TFerdinand.netTeddy FERDINAND

Comprendre que la croissance prend du temps

Votre premier cercle de lecteur sera souvent votre entourage : famille, ami, collègues de travail, etc.

Augmenter son nombre de lecteurs est quelque chose qui prend du temps, beaucoup de temps, et la patience est indispensable.

Écrire pour le plaisir

Je terminerais avec ce conseil, tout aussi important que le premier. Écrire doit rester un plaisir.

Tomber dans le batch pour faire de l'écrire risque de vous dégouter. Écrivez quand ça vous plait, sur ce qui vous plait.

De même, écoutez les retours de vos lecteurs, mais ne vous focalisez pas dessus. Pour ma part, j'ai eu ma dose de haters, et même si ça me gênait au début, je n'y prête même plus attention!

Je vois souvent passer des communications indiquant qu'il faut faire des mots de passe avec beaucoup de caractères, car cela les sécurise, avec de jolis graphes qui expliquent qu'il ne faut que quelques secondes pour casser un mot de passe à 8 caractères.

C'est à la fois vrai et faux.

Aujourd'hui, je vais vous partager mon avis sur ce sujet.

Avoir un mot de passe fort est important...

...mais ce n'est pas la seule chose importante

Il est évident qu'il est indispensable d'avoir un mot de passe fort pour sécuriser ses différents accès.

Par mot de passe fort, j'entends :

• Minimum 12 caractères
• Mélange de majuscules et minuscule
• Présence de chiffres et caractères spéciaux
• Unique pour chaque site

J'ajouterais aussi qu'il est important que ce mot de passe ne reprenne pas quelques informations "personnelles", telle que :

• Nom des animaux de compagnie
• Date de naissance
• Prénom des enfants, conjoint etc.

Pourquoi? Car cela permet de vous protéger des attaques par dictionnaire.

En effet, l'un des modèles d'attaque courant consiste à se renseigner un minimum sur sa cible, avec les réseaux sociaux par exemple, pour construire un dictionnaire, permettant de créer des combinaisons de mot de passe possibles.

A chaque site son mot de passe

Plus important encore que la complexité du mot de passe, son unicité est un critère primordial.

Pourquoi ? Tout simplement parce que des sites se font pirater tous les jours et toutes les entreprises sont ciblées.

L'intérêt est donc en cas de compromission d'un site de réduire énormément le blast radius et éviter que l'ensemble de vos comptes soit compromis en un coup.

A ce titre, je vous invite fortement à vous inscrire sur HaveIBeenPwned.com afin de voir si votre adresse mail s'est retrouvée dans un leak.

Exploiter autant que possible l'authentification à facteur multiple

L'authentification à facteur multiple, ou MFA (Multiple Factor Authentication), permet de complexifier une attaque en demandant une information supplémentaire à l'utilisateur pour l'identifier.

Cela peut être, sans être exhaustif :

• Une clé physique, comme les célèbres YubiKeys
• Un code unique, avec des applications comme Authy, ou un générateur physique
• Un code envoyé par mail, SMS, appel téléphonique, etc.

Responsabilité du développement

Limiter la communication à indiquer qu'il faut créer un mot de passe sécurisé est insuffisant.

Il est aussi indispensable de mettre en place de bonne pratiques de développement, petit tour d'horizon.

Exponential backoff

Derrière ce terme barbare se cache l'un des concept qu'on retrouve souvent dans les webservices.

L'idée ici est qu'a chaque mot de passe erronné, on interdit à l'utilisateur de se connecter pendant un certain laps de temps, de plus en plus grand.

C'est ce que font la plupart des systèmes Linux par exemple.

Cela permet de réduire grandement la facilité avec laquelle on va pouvoir "brute force" un compte, c'est à dire tenter de casser le mot de passe en essayant beaucoup de combinaisons.

Ainsi, même avec un mot de passe plus faible, les possibilités restent réduites.

Toutefois, pour que ce modèle soit efficace, il est important de prendre en compte les points suivants :

• Toutes les attaques ne ciblent pas forcément un seul compte, certains attaquant vont cibler une liste de compte et tourner entre les comptes pour attaquer et être moins visible, sur ce point, on filtre souvent en exploitant les adresses IP, en interdisant les tentatives d'affilées depuis la même adresse.
• Empêcher les tentatives d'affillée sur le même compte, même depuis plusieurs IP. Cela permet par exemple de se protéger contre les attaques effectuées par des botnets.

Ces protections vont être pertinentes avec des modèles d'attaques courants.

De plus, il faut aussi se méfier des attaques slow rate. Ces attaques vont utiliser les mêmes modèles que précédemment, mais avec une fréquence faible, pour essayer de passer sous les radars. D'où l'importance de bien surveiller les tentatives d'accès!

On peut aussi aller plus loin en implémentant en plus une solution antibot, comme j'en ai parlé par le passé :

La difficulté de la lutte antibot sur le web

Les robots, appelés plus couramment bots, pullulent aujourd’hui sur Internet. Il représente une part du trafic Internet global non négligeable. Aujourd’hui, je vous propose de découvrir le monde des bots de l’Internet. Des bots… mais pour quoi faire ?La première question que l’on pourrait se poser

TFerdinand.netTeddy FERDINAND

Ne pas donner trop d'informations en cas d'erreur

Je l'ai déjà dit : l'information, c'est le pouvoir.

Même si un utilisateur légitime sera heureux de savoir s'il s'est trompé sur son login, son mot de passe, si son compte est verrouillé etc., cela reste une informations pertinente pour un attaquant, lui permettant de savoir comment orienter son attaque.

L'un des exemples est d'utiliser les formulaires de login pour faire de l'énumération d'adresse mail, quand le formulaire réponds gentiment "je ne connais pas ton adresse mail".

Ainsi, quelque soit le problème d'authentification, il est conseillé de toujours répondre le même message, le plus générique possible.

Ajouter du sel à la recette

La sécurisation des mots de passes passe aussi par leur stockage.

En cas de compromission d'une base de donnée, le but est de complexifier autant que possible le boulot du hacker.

Pour cela, la technique la plus commune (et simple) reste le basique, mais efficace salt + hash.

Cette technique consiste à ajouter un chaine de caractères en supplément du mot de passe, si possible unique pour chaque utiliteur.

Cela permet d'avoir des hash moins facilement reversible (par dictionnaire).

Auth0 a publié un bon article sur le sujet, que je vous invite à lire si vous voulez en savoir plus.

Adding Salt to Hashing: A Better Way to Store Passwords

A salt is added to the hashing process to force their uniqueness, increase their complexity without increasing user requirements, and to ...

Auth0 - BlogDan Arias

Pour finir

Les points que je cite ici ne sont pas exhaustifs, mais consiste pour moi dans le socle solide qui permet de sécuriser un peu plus vos comptes.

La meilleure manière de générer un mot de passe unique et sécurisé pour chaque site reste l'utilisation d'un password manager, comme keepass, bitwarden, etc.

Pour ma part, j'exploite bitwarden, qui me permet de générer et stocker des mots de passe forts et uniques, comme vous pouvez le voir ci dessous.

N'hésitez pas à rajouter en commentaires les points qui vous semblent indispensables.

Cela fait quelques années que je fais passer régulièrement des entretiens techniques. Dans ce billet, j’ai voulu vous compiler un peu mes astuces/remarques/points (rayez la mention inutile) afin que ces derniers se passent au mieux pour vous.

Comme indiqué dans le titre, ce billet s’adresse plus particulièrement aux profils juniors (sans aucune condescendance), mais chacun peut y trouver des points utiles.

Avant l’entretien

1) Se renseigner sur l’entreprise

Lorsque vous allez en entretien, cela signifie que vous envisagez de rejoindre une entreprise. Le mieux dans ce cas est de vous renseigner un minimum sur celle-ci. Cela passe par le site institutionnel de cette dernière, son (ou ses) blog(s), mais aussi des sites tiers qui permettent d’avoir les avis des employés actuels ou passés.

Cela permet d’avoir un discours pluriel et donc de savoir dans quoi l’on s’engage. Rien n’est pire qu’une entreprise au management toxique par exemple. Eventuellement, cela vous permet aussi de poser des questions supplémentaires lors de l'entretien pour en savoir plus sur l'entreprise.

2) Préparer sa présentation

C’est souvent ma première question en entretien : "J’ai votre CV devant moi, mais j’aimerais que vous m’en parliez vous-même". Non pas que je n’ai pas lu le CV (je lis les CV très attentivement au contraire), mais je veux savoir ce que vous voulez me présenter. La manière dont vous allez présenter votre CV va influencer l’entretien. Pour ma part, c’est ce qui me permet de voir les choses que vous avez réellement travaillées ou les buzzwords présents dans le CV.

De même, de manière assez naturelle, ça va permettre de voir ce que vous considérez comme important ou mineur dans votre expérience. Attention toutefois à ne pas tomber dans la récitation par cœur. Restez naturel, c’est votre expérience, donc la manière dont vous le racontez doit être aussi unique que votre CV l’est.

3) Attention au piège des buzzwords

Il peut être tentant de mettre sur votre CV une flopée de buzzwords de technologies à la mode. C’est en partie ce qui fera que vous serez remarqués.

Attention toutefois, lors de l’entretien technique vous aurez (souvent) quelqu’un avec un bon bagage technique. Son job : déceler le vrai du faux dans ce que vous dites savoir faire.

Un CV trop shiny est suspect sur quelqu’un avec peu d’expérience, et autant se le dire tout de suite, un expert verra en une à deux questions si vous essayez de le baratiner.

Si vous mettez une technologie, un sujet, une méthodologie, vous devez vous attendre à ce qu’on vous demande d’en parler, donc il faut que vous sachiez un minimum en parler, donc n’hésitez pas à réviser vos bases en amont. Tout ce qui est sur votre CV équivaut à une question possible.

4) Identifier les attentes

Si vous avez fait quelques recherches sur l’entreprise (premier point de cette section pour ceux qui n’ont pas suivi), vous savez quelles sont les attentes de l’entreprise. Vous savez donc quels sont les sujets que vous devez maîtriser mieux que d’autres, mais aussi comment orienter votre discours. Comme j’aime à le dire, un entretien est une vente : vous vous vendez à l’entreprise. Vendez donc un produit adapté à l’entreprise. Savoir que vous avez fait de la pêche est sans doute un point que vous avez aimé dans votre carrière, mais est-ce que ça vous apporte quelque chose pour manager un cluster Kubernetes ?

Bonus) Avoir des réalisations à présenter

Je le met en bonus, car ce n'est pas pour moi un vrai prérequis mais plutôt quelque chose qui peut aider à convaincre.

Il peut parfois être pertinent d'avoir du contenu que vous publiez et que vous pouvez partager avec le recruteur. Par exemple, pour ma part, j'ai déjà présenté ce blog.

Il peut aussi s'agir de repository GitHub, de vos contributions à de l'open source, d'intervention dans des conférences, etc.

Il s'agit simplement de bonus, mais c'est un bon élément pour démontrer vos compétences.

Pendant l’entretien

5) Posez des questions

L’entretien technique est aussi l’occasion pour vous, candidat, de mieux connaître l’entreprise. Un entretien va dans les deux sens, vous devez convaincre l’entreprise, mais l’inverse est aussi vrai. Il ne faut pas hésiter à poser des questions, sur le fonctionnement de l’entreprise, le quotidien des personnes au même poste, etc.

Ces questions vous permettront de savoir où vous mettez les pieds, c’est un point tout aussi important que convaincre votre interlocuteur.

6) Prenez des notes

N’hésitez pas à prendre des notes de ce qu’on vous donne comme information, si on vous demande de synthétiser votre réflexion, il ne faut pas non plus hésiter à schématiser : un bon schéma vaut mille mots !

Ce point est d’autant plus important si on vous donne un sujet de réflexion : notez les points que vous identifiez comme important, ça vous permettra de vous assurer de ne pas répondre à côté du sujet.

7) Moins de "Je", plus de "Nous"

Quand vous rejoignez une entreprise, vous rejoignez souvent une équipe, et vous en quittez souvent une autre.

Savoir ce que vous avez fait dans vos précédentes expériences est évidemment important, mais la manière dont vous le présentez l’est tout autant.

Personnellement, je me méfie beaucoup des candidats qui utilise "Je" à chaque phrase plutôt que "Nous". En tant que junior, il est assez rare d’avoir tout fait en solo, il n’y a aucune honte à l’indiquer. Au contraire, cela peut être rassurant de savoir que vous "ne jouez pas perso". Une entreprise, c’est un ensemble de gens qui sont censés aller dans le même sens.

Attention toutefois, le but n'est pas de vous effacer complétement, il est important de savoir ce que vous savez faire de vous même, en solo!

8) "Je ne sais pas" est une réponse acceptable

C’est l’une des premières remarques que je fais en entretien : "Je ne sais pas" est une réponse acceptable. Il n’y a aucune honte à ne pas avoir réponse à tout, au contraire, c’est humain.

Par contre, si vous me dites que vous êtes expert Docker, et qu’une première question de base (par exemple, comment limiter le CPU utilisé par un container) a comme réponse "Je ne sais pas", ce n’est pas forcément rassurant.

9) Parfois, il n’y a pas de bonne réponse

Pour poursuivre le point précédent, parfois, il n’y a pas de bonne réponse. Dans les mises en situation que je fais en entretien, la solution m’importe souvent peu. Ce qui va m’intéresser bien plus par contre est la réflexion qui va mener à l’idée.

Petit exemple, vous me dites que vous allez héberger une solution sur AWS, ma prochaine question va être "Pourquoi AWS, et pas GCP ?". Le but est de comprendre le cheminement qui vous a conduit à ce résultat, pas forcément le résultat en lui-même.

10) Sortez du lot, mais attention

Le but d’un entretien est évidemment de sortir du lot, il faut que vous montriez qu’il vaut mieux vous embauchez vous que quelqu’un d’autre, mais attention, être trop atypique peut aussi jouer contre vous. Le but est que vous rejoignez une équipe, une entreprise et rien n’est pire qu’un électron libre. Sortir du lot, se démarquer est bien, mais il faut savoir où se trouve les limites, se démarquer trop peu aussi effrayer votre employeur potentiel. Restez vous même, tout en fixant éventuellement des limites.

Après l’entretien

11) Faire confiance à son ressenti

Comme je l’ai dit plus haut, un entretien va dans les deux sens. C’est pourquoi il est important de noter aussi son ressenti. Si vous n’avez pas un bon feeling suite à l’entretien, faites vous confiance. Mieux vaut "rater" une opportunité que de s’engager dans une entreprise où l’on ne va pas se sentir bien. C’est un point qu’on sous-estime souvent, mais le mental est aussi important que le salaire que vous demandez.

Être dans une entreprise ayant des comportements toxiques finira par vous peser à un moment ou à un autre… Je sais de quoi je parle à ce sujet.

12) Ne pas hésiter à demander un feedback

Que l’entretien soit positif ou non, il ne faut pas hésiter à demander un retour. Il y a toujours des points sur lesquels on peut s’améliorer, avoir un regard extérieur peut parfois vous permettre de les mettre en exergue.

À titre d’exemple, suite à mes entretiens chez WeScale, voici ce que j’avais eu comme feedback :

Je n’ai aucune gêne à les partager, ce sont des points que j’ai accueillis très favorablement. Savoir on l’on a "réussi" l’entretien, mais aussi identifier les axes d’amélioration est primordial pour continuer d’évoluer. Cela permet aussi d’en savoir plus sur ce que l’entreprise a vu suite à vos échanges.

Pour résumer

Un entretien est bidirectionnel, ne l’oubliez pas. Si vous voulez maximiser vos chances, n’hésitez pas à le préparer un minimum.

Il n’est pas nécessaire de connaître l’entreprise sur le bout des doigts, mais simplement de savoir ce qui vous attend en avance.

De même, faites confiance à votre instinct, si vous avez un mauvais ressenti suite à votre entretien, il est peut-être nécessaire de vous demander si c’est ce que vous voulez au quotidien.

Et vous, avez-vous d’autres astuces à partager ? N’hésitez pas à réagir dans les commentaires !

L’année 2022 commence, l’occasion pour moi de vous livrer ma vision des tendances dans l’IT et la sécurité.

Comme souvent dans mes billets, il s’agit de mon avis, et vous avez le droit de ne pas être d’accord avec moi.

Dans tous les cas, n’hésitez pas à donner votre point de vue dans les commentaires, aucune inscription n’est nécessaire.

La part du télétravail va augmenter

On l’a vu depuis le début de la pandémie du Covid, le télétravail permet aux entreprises de continuer leur activité malgré les aléas sanitaires.

Même si c’est encore partagé, de nombreuses entreprises ont dû "lâcher du lest" à ce propos et accepter du télétravail, à minimum partiel.

Cette pandémie a aussi été, pour beaucoup de monde, l’occasion de se recentrer sur ses priorités, et le télétravail offre plus de souplesse pour sa vie privée. Cela va même jusqu’à une part non négligeable de personnes qui quittent leur travail pour faire la même chose ailleurs… mais à distance !

Ce que j’espère, pour ma part, est que cela ne va pas contribuer à la précarisation de nos métiers, en ne voyant dans le télétravail qu’une manière de réduire les coûts.

C’est l’un des points que j’avais remonté en fin d’année.

Aussi, il est encore nécessaire de voir si cela va survivre à la pandémie. Actuellement, beaucoup d’entreprises le font, car elles y sont fortement incitées : si elles ne le font pas, elles recrutent bien plus difficilement. Une fois cette pandémie passée (du moins je continue d’espérer qu’elle va passer), il est probable que les "vieux démons" du présentéisme reviennent. Reste à voir si certains auront compris que leurs équipes sont tout aussi efficaces à distance !

La part de la cybersécurité dans les budgets IT va continuer de grossir

Ces dernières années, la part de budget allouée à la cybersécurité a augmenté dans beaucoup d’entreprises.

Avec une fin d’année mouvementée au niveau de la sécurité, notamment avec les failles log4j, la sécurité des entreprises est revenue sur le devant de la scène.

Le nombre d’attaques ne faisant qu’augmenter d’année en année, il va être nécessaire d’investir massivement dans ce domaine.

Il reste pour moi un principal souci : il n’y a actuellement pas assez de monde formé pour répondre à ce besoin sur le marché. Même si les formations en cybersécurité se développent de plus en plus, il est probable qu’il faille encore quelques années avant de trouver plus facilement de la main-d’œuvre dans ce domaine, ce qui va donc faire encore monter les prétentions salariales/TJM pendant un petit moment.

La blockchain va commencer à se montrer dans les entreprises

Mot bullshit pour certain, l’avenir pour d’autres : la blockchain.

Je ne parle pas ici de ces implications spéculatives (Bitcoin, Etherum et leurs petits copains), mais du protocole en lui-même.

Certaines entreprises ont tenté le coup en cette fin d’année avec des NFT, et certaines ont aussi fait marche arrière devant leur communauté.

Toutefois, la blockchain a pour moi de vrais intérêts dans l’industrie, notamment pour la traçabilité des informations. Par exemple, dans le domaine alimentaire, cela permettrait de tracer de manière fiable la chaine complète d’un aliment, que le consommateur pourrait consulter. L’inaltérabilité et la fiabilité de ce protocole pour stocker un suivi en fait l’enveloppe parfaite.

Je fais partie des gens qui observent encore ce protocole actuellement. Pour ma part, je considère qu’on a aujourd’hui une ébauche de ce que sera la blockchain d’ici quelques années. On le voit avec l’évolution de ce protocole sur les 5 années passées, et je pense qu’il va continuer d’avancer pour être plus rapide, et continuer d’aller vers une sobriété énergétique indispensable à l’avenir de l’humanité.

L’écologie va être un argument commercial

Bon, en vrai c’est déjà le cas avec le greenwashing qui traine ces dernières années.

Toutefois, quand AWS annonce qu’ils vont mettre à disposition le compte rendu énergétique auprès de leur client chaque année et le fait que la "sustainibility" est été intégrée aux piliers d’AWS est une étape dans la bonne voie de mon point de vue.

New – Sustainability Pillar for AWS Well-Architected Framework | Amazon Web Services

The AWS Well-Architected Framework has been helping AWS customers improve their cloud architectures since 2015. The framework consists of design principles, questions, and best practices across multiple pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimiza…

Amazon Web Services

Maintenant, j’espère que d’autres clouds providers vont emboiter le pas, et surtout que cela va avoir un impact sur le fonctionnement des entreprises.

Savoir l’impact que l’on a est la première étape pour le réduire.

Les IA vont continuer à se perfectionner

Autre mot bullshit ces dernières années : l’IA.

Derrière ce mot, on peut tout cacher, tant que c’est automatique !

Toutefois, pour moi, je vois surtout le machine learning (et le deep learning) qui vont continuer de se développer. Cela fait quelques années que les géants de la tech l’ont compris : l’IA accélère les décisions et sait anticiper les besoins.

Attention toutefois : l’IA reste guidée par ce qu’on lui donne pour apprendre, et peut donc avoir les mêmes biais que les humains.

C’est le résultat d’une expérience d’Amazon il y a quelques années par exemple, en voulant créé une IA pour accélérer le recrutement, basé sur les décisions de leurs recruteurs humains, ils se sont aperçu que le scoring des profils féminin était toujours plus faible.

Amazon scraps secret AI recruiting tool that showed bias against women

Amazon.com Inc’s <AMZN.O> machine-learning specialists uncovered a big problem: their new recruiting engine did not like women.

ReutersJeffrey Dastin

La raison : les recruteurs rejetaient plus facilement les profils de femmes, donc l’IA a appris depuis ce modèle.

L’IA, c’est aussi le deepfake, les "vous aimerez aussi" des sites Internet, le développement simplifié (avec GitHub CoPilot par exemple) et bien d’autres domaines.

À suivre donc !

Commençons cette nouvelle année !

Voilà donc mes 5 plus grandes prédictions pour cette année. Je ne pense pas avoir pris de gros risques, car ce sont des sujets incontournables pour nombre d’entreprises.

Il ne faut pas oublier l’effet de mode aussi : certaines entreprises vont utiliser des technologies parce que les concurrents ou les bigtech vont le faire. C’est à nous, professionnels de l’IT, de savoir les guider pour éviter ces dérives. Évitons un énième effet Kubernetes partout/Modèle spotify (rayer la mention inutile).

Rendez-vous en 2023 pour voir si j’ai vu juste !

Et vous quelles sont vos prédictions ?

D’accord, pas d’accord, n’hésitez pas à indiquer dans les commentaires vos prédictions pour l’année 2022, il y a sans doute des points que je n’ai pas couverts et votre avis compte aussi !

Sur les réseaux sociaux, blog et autres publications, on parle très souvent de nos réussites (moi le premier). Aujourd’hui, j’ai décidé de vous parler d’un de mes "échecs" (notez les guillemets) récents : le jour où j’ai compris que je ne faisais pas du bon code.

Résumé d’un drame en trois actes.

Situation initiale : seul au monde

J’ai commencé chez mon client actuel (le groupe SeLoger) en octobre 2019. À ce moment, je remplace quelqu’un de mon ESN (WeScale) qui quitte ce client.

Ma mission consiste a évaluer la sécurité AWS des comptes, puis de proposer des solutions, voire les mettre en place.

L’un des piliers que je propose et développe (en repartant de ce que mon prédécesseur avait fait) est donc de mettre un IAM (Identity and Access Management) fort sur AWS.

Vu mon passé d’Ops/FinOps/Architecte, l’automatisation, la fiabilité et la vitesse d’exécution sont des critères importants.

De même, je ne veux pas créer un gouffre entre les équipes DevOps et moi et j’ai donc besoin d’un outil que tout le monde (ou presque) puisse prendre en main.

J’ai donc développé plusieurs outils, principalement en python, dont le job principal est de déployer des permissions et de faire des liens avec des utilisateurs, de manière automatisée.

Je commence donc l’onboarding des applications, et de 25 repositories exploitant ces permissions, on arrive au bout d’un an à plusieurs centaines.

C’est là que les choses commencent à se gâter…

L’élément perturbateur : le scaling

Je commence à percevoir les limites de ce que j’ai mis en place :

• Les permissions IAM ne sont pas optimisées, et sont parfois redondantes
• Je tape parfois des limites de tailles de policies AWS suite au point précédent (J'en ai d'ailleurs parlé dans le passé)
• Le déploiement des droits utilisateurs tombe parfois en timeout (et dure plusieurs heures !)
• Je dois ajouter des fonctionnalités, mais mon script est devenu un gros tas de scotch au fur et à mesure des patches

De là, mon constat : un refacto est nécessaire. Si je veux pouvoir continuer d’ajouter des fonctionnalités quand les nouveaux besoins se manifestent, il me faut une base de code remise à plat.

Je défends donc cette idée auprès de mon manager (client) qui comprend effectivement l’intérêt et me donne donc le go pour faire ce travail.

Tout seul, on va vite, ensemble, on va loin

Nous sommes à ce moment en octobre-novembre 2020. Ce refacto est donc dans mon backlog, et il est prévu que je m’attarde dessus fin décembre/début janvier.

Au début de l’année, du renfort qui arrive. Un de mes collègues de WeScale arrive sur la mission pour me prêter main forte. Ce dernier a un bagage plus teinté développeur, là où j’ai un bagage très teinté Ops de mon côté.

Je lui présente donc un peu ce que j’ai fait, et je perçois assez vite qu’il voit des choses complexes ou qui ne sont pas à l’état de l’art.

J’essaie de le rassurer en lui disant que je travaille sur une remise au propre de tout ça pour repartir sur des bases saines.

Je travaille donc sur mon refacto, et assez vite, je lui soumets donc en code review mon code. J’échange avec lui en partageant la PR, et là, je me rends compte que la réaction n’est pas celle que j’attendais.

En effet, en échangeant avec lui, je perçois que ça reste bien trop complexe, et pas vraiment "clean", même sur ma nouvelle version.

Sur le coup, mon ego en prend un coup, et je me braque un peu. C’était en soirée, on arrête là, en se disant qu’on en reparlera au calme le lendemain.

Bien entendu, le soir, je cogite. Je me rends assez vite compte qu’il n’a pas tort : je ne suis pas un développeur. C’est le constat que je fais, jusqu’à présent, j’ai scripté des choses pour répondre à des besoins, mais je n’ai jamais vraiment développé.

Le lendemain, en discutant, je lui explique donc ce point : j’ai besoin d’aide pour savoir ce que je dois (re) voir. S’en suit une (très) longue discussion dans lequel il m’expose certains points qui pour lui ne vont pas :

• Mon code est un seul script, ce qui empêche de l’étendre facilement
• Le code est dans le même repository que la configuration des projets, ce qui ne lui permet pas d’avoir son cycle de vie propre
• En l’état, on ne peut pas tester ce que j’ai fait
• Le découpage de mon code n’est pas clair, certaines fonctions ont une complexité trop élevée

Une fois de plus, grosse claque pour l’ego, bien que les propos soit bienveillants, ce que j’entends c’est "ton code c’est de la merde" (ce qui n’était pas du tout le discours de mon collègue).

Le dénouement : apprendre à développer

Je n’ai pas de honte à le dire, ça a été une période assez violente pour moi, j’ai en effet dû appréhender beaucoup de concepts de développement assez rapidement :

• Structurer physiquement mon code (structure des répertoires)
• Structurer fonctionnellement mon code (logique du code)
• Apprendre à packager proprement
• Apprendre la base des tests unitaires
• Basculer sur une logique d’objet
• Revoir l’algorithmie

Et j’oublie sans doute des sujets. De plus, je suis donc dans une grosse remise en question sur la qualité de mon travail.

L’autre point que j’ai dû apprendre est de faire du développement "partagé", que quelqu’un d’autre doit être en mesure de comprendre/reprendre. Jusqu’à présent, bien que je sois en équipe, je développais souvent pour les besoins de mes projets, en solo.

La semaine suivante, je relivrais une préversion de mon script, qui était devenu entre temps une vraie application python, avec son repository, son pipeline de test, des precommit, et un push sur un Nexus du paquet final.

J’ai senti dès lors que le positionnement de mon collègue avait changé. Déjà, nous avions validé ensemble (dans les grandes lignes) la logique du code, ce qui faisait que l’ensemble était de fait plus lisible. Ensuite, j’avais aussi pris en compte au maximum ses remarques, et j’avais même poussé certains points plus loin que ce qu’il m’avait indiqué.

La structure même du code était, même pour moi, bien plus pertinente, et je pouvais voir facilement comment l’étendre en fonction des besoins.

Après quelques aller-retour sur des points qu’il avait remarqués (wording, algorithme, axes d’amélioration du code, etc.), ma PR était validée, et nous poussions la nouvelle version de l’application (dont 95 % du code avait changé) en production.

En conclusion : ce que j’ai appris

Pour conclure ce billet, je dirais que l’un des points les plus importants que j’ai appris durant ces derniers mois, c’est qu’il n’y a pas de honte à ne pas savoir. Pour ma part, je suis dans une démarche d’amélioration continue, et j’aime apprendre de nouvelles choses. Je considère que c’est une grosse partie de la richesse de nos métiers : nous n’avons jamais fini d’apprendre.

De plus, j’ai aussi compris qu’on ne s’improvise pas développeur, il y a beaucoup de concepts à appréhender :

• Lisibilité du code
• Testing
• Algorihmie
• Complexité
• Documentation
• Développer aujourd’hui, mais préparer demain en ayant un code potentiellement extensible

Ce sont des points sur lesquels je suis encore en train de monter en compétence (notamment la partie test qui est loin d’être simple pour quelqu’un qui débute).

De plus, cela a changé aussi ma manière de développer, je commence à avoir le réflexe de créer quelques tests avant d’écrire le code associé, je découpe beaucoup plus mon code en petites fonctions atomiques qui n’ont qu’un rôle bien défini, j’essaie d’utiliser des structures optimisées en fonction de mon besoin et j’en passe.

Enfin, l’un des points importants est que la critique peut parfois faire mal, mais c’est ce qui permet d’avancer. À ce sujet, je partage d’ailleurs beaucoup de choses remontées sur le blog jesuisundev par Mehdi Zed :

Comment bien donner et recevoir une code review (sans drama)

La code review est l’un des outils les plus bénéfiques et formateurs pour un développeur. Sauf quand c’est mal fait.

Je suis un devjesuisundev

J’espère que ce billet vous a plu, et n’oubliez pas : l’échec, même temporaire, n’est pas une fatalité, c’est en faisant des erreurs que j’ai le plus appris pour ma part ! En soi, le code que j’avais fourni à l’origine n’était pas catastrophique, il répondait à mon besoin à l’instant T, mais il ne permettait pas de répondre aux besoins futurs.

Aujourd’hui, quand je regarde le code que j’ai fourni ces derniers mois, je sens bien que je ne suis plus au même niveau, et j’avoue que suis fier d’arriver un livrer un code bien plus propre et maintenable.