J'observe le monde de l'IT depuis plusieurs années, et dernièrement la mode est de balancer des PowerPoint remplis de « AI-first » : agents autonomes qui scalent l’infra, corrigent les vulnérabilités seuls, génèrent du code sécurisé en 30 secondes… et la promesse que dans six mois on n’aurait plus besoin ni d’ops juniors, ni d'équipe sécurité, ni même de devs « classiques ».

J’ai souri en voyant ces takes. Parce que j’ai déjà vécu ça. Je suis dans le monde de l'IT, et plus précisément de l'infra/secu, depuis presque 20 ans et je code encore pour mes équipes ou mes propres outils, je sais exactement comment ça finit.

Back to the future

Remontons un peu le temps.

Ça va vous parler.

• Il y a 5 ans (2021) : on embauchait des « prompt experts ». Des gens payés très cher pour écrire les cinq lignes magiques qui faisaient marcher les premiers modèles avec des besoin complexes. J’ai vu des équipes entières passer des journées à tweaker des prompts pour que le LLM sorte un aws_iam_role ou un rule de WAF sans tout casser.
• Il y a 3 ans (2023) : place aux LLM experts. Fine-tuning sur des runbooks, réécriture des docs internes, eval loops sur des pipelines CI/CD. On passait du sorcier du prompt au data scientist qui savait vraiment ce qu’il faisait.
• Il y a 2 ans (2024-2025) : le vibe coding a tout emporté (le terme lancé par Andrej Karpathy en février 2025 : « fully give in to the vibes, embrace exponentials, and forget that the code even exists »). N’importe qui (même moi un dimanche soir) sortait du Terraform, du code applicatif ou des règles de détection qui « avaient l’air propres ». Impressionnant sur le moment. Jusqu’au jour où ça partait en prod avec des secrets hardcodés, des endpoints ouverts ou des permissions IAM hallucinées.
• L’année dernière (2025) : l’automatisation globale. Des agents partout. Des « AI cybersoc employees » et « AI devs » censés remplacer des équipes entières. Des millions claqués dans des outils qui promettaient de monitorer, scaler, patcher et sécuriser tout seuls. On y était presque, franchement.
• Et puis… ces derniers mois (début 2026).On commence à voir le retour de bâton, et il est violent (surtout quand on porte la casquette cybersoc). Les boîtes qui ont poussé l’IA « de force » se retrouvent avec du technical debt monstrueux : des agents qui hallucinent sur des permissions IAM (et donnent des droits admin à tout le monde, créant du « identity dark matter »), des pipelines qui marchent en démo mais cassent à 3h du mat avec des coûts cloud qui explosent, des agents vulnérables à la prompt injection via des données malveillantes, et des outils misuse qui escaladent les privilèges sans que personne ne le voie.

Retour à la réalité

Résultat ? On réembauche des experts. Des vrais cybersoc, ops et devs. Pour corriger, superviser, « parenter » l’IA comme un ado surdoué mais complètement irresponsable.

J’ai lu récemment deux articles qui résument parfaitement ce moment.

Le premier, sur Gravitee (janvier 2026) : « Lessons Learned From Exposing Real APIs Through MCP ». Ils ont vraiment exposé des APIs d’entreprise (pas des mocks) via un serveur MCP et l’ont mis entre les mains d’agents autonomes. Leur conclusion ? Le MCP ne remplace rien. Il révèle juste toutes les faiblesses qu’on avait cachées : schémas ambigus, gestion d’erreurs fragile, contrôle d’accès trop permissif, latence qui tue les workflows agents.

Certaines citations m’ont fait sourire :

If you’re building for agents, your APIs need to grow up a little.

Treat MCP not as a shortcut, but as an interface that deserves the same care as any public API.

Exactement : une API solide (et sécurisée) reste largement meilleure.

Le MCP est cool, mais si ton backend a des scopes trop larges ou des erreurs mal gérées, les agents vont juste créer des brèches sans le vouloir.

Le second sujet qui tourne partout : le cycle complet de la hype. Gartner est très clair : l’IA générative est en plein Trough of Disillusionment. Malgré un spending mondial énorme, les entreprises peinent à montrer du ROI (Retour sur investissement) concret.

Et là, on touche le point qui fait mal : le rapport MIT Media Lab/Project NANDA (2025) qui dit que 95 % des pilotes GenAI n’ont généré aucun retour mesurable. Des milliards investis et… rien (ou presque rien). Comme on le dit souvent : "Pendant la ruée vers l'or, ce ne sont pas les chercheurs d'or qui se sont le plus enrichis, mais les vendeurs de pelles et de pioches"

Les CFO commencent à tuer les projets un par un. On est passé de « l’IA va tout sécuriser et scaler » à « ok, on va peut-être d’abord faire des APIs, une infra et des guards qui ne cassent pas ».

J’ai vu des équipes qui ont laissé des agents générer 80 % de leur Terraform ou de leur code applicatif : beau sur le papier, illisible en prod, impossible à debug et plein de vulnérabilités (secrets dans le code, endpoints publics, règles de détection qui laissent passer l’essentiel).

Des coûts inference qui dépassent la facture infra classique parce que l’agent retry 47 fois sur un endpoint lent (et qui exposent des données sensibles au passage).

Et on n’est plus dans la théorie : depuis fin 2025, on a déjà vu ça en vrai.

• Décembre 2025 : l’agent Kiro d’Amazon décide tout seul de supprimer et recréer une partie de l’environnement de prod → 13 heures d’outage sur AWS Cost Explorer.
• Un deuxième incident similaire avec Kiro/Amazon Q : ingénieurs laissent l’IA faire des modifs autonomes → outage à cause de rôles IAM mal configurés.
• Et côté attaque : un environnement AWS compromis en 8 minutes seulement, grâce à un attacker qui utilise des LLM pour escalader via des creds trouvées dans un S3 public (rapport Sysdig, février 2026).
  Preuves d’IA partout : hallucinations, code qui escalade sans que personne ne voie.

Bref, le vibe coding + agents a créé exactement le même chaos que quand tout le monde a migré vers le cloud en 2010 sans gouvernance : on a tout cassé (et ouvert des portes), puis on a réembauché des gens qui savaient vraiment.

Alors oui, on avait déjà des incidents et gens qui commitait n'importe quoi sur Github bien avant l'avénement des IA, mais ce problème s'est largement intensifié ces dernières années.

L'âge de la maturité

C’est juste la maturation normale. Comme le cloud, comme les containers, comme Kubernetes. On a eu la hype, la dette technique, et maintenant la phase « on reprend les bases mais en mieux » avec une vraie couche de sécurité.

Aujourd’hui on entre dans la phase « parenting AI ». On va avoir besoin de profils hybrides qui savent :

• Découper les tâches en petits morceaux clairs (pas de prompts vagues)
• Exiger que l’IA montre son travail (logs, raisonnement, schéma explicite)
• Mettre des guards solides avant tout (policy as code, IaC linting renforcé, MCP avec rate limiting, observability et least-privilege strict)

Et surtout : comprendre le métier (cybersoc, infra, dev) avant de tout automatiser.

Ma conclusion

Moi je continue à jouer avec tout ça au quotidien. Mais je garde mon œil de vieux briscard : une bonne vieille API bien typée, documentée, avec des erreurs structurées, des scopes serrés et une vraie gouvernance IAM reste mon meilleur ami. L'IA est composé d'outils incroyables qui changent notre manière de travailler et nous assite au quotidien.

Le reste, c’est du bonus.

Et maintenant ? Mes 3 conseils concrets:

• Arrête les pilotes « fun ». Exige du ROI mesurable sur un process précis (ex : réduction de 30 % du temps de remédiation sans ouvrir de nouvelles brèches).
• Renforce tes APIs avant de les exposer via MCP ou agents. Lis l’article Gravitee, applique les règles : schémas explicites, erreurs avec retry guidance, scopes minimaux + security reviews.
• Réembauche ou forme des « AI validators » dans ton équipe. Pas pour coder tout seuls, mais pour reviewer ce que l’IA sort, surtout sur les aspects sécurité et permissions.

Et vous ? Vous en êtes où dans le cycle ? Toujours en mode full agents pour votre cybersoc, infra ou dev ? Déjà en train de tuer des projets et de réembaucher des humains ? Ou vous avez trouvé le sweet spot entre vibe et rigueur (avec de la vraie sécu) ?

Il y a quelques jours, la beta ouverte de Battlefield 6 était disponible.

Lors de l'installation du jeu, j'ai constaté, une fois de plus, que le programme anti triche (anti-cheat) d'EA s'installe au niveau du ring 0 (je reviendrai sur ce concept plus bas, pas de panique! 😄).

Les tricheurs étant de plus en plus prolifiques, les éditeurs de jeux vidéos ont du trouver de nouvelles parades pour identifier et bloquer le plus rapidement les nouvelles manières de tricher en jeu.

Protection ring

Pour comprendre comment fonctionnent certains anti-cheats, et pourquoi ils posent problème, il me faut d’abord expliquer le principe des protection rings.

De manière imagée, il faut penser votre système comme un oignon : plusieurs couches concentriques, du plus protégé au plus exposé.

• Ring 0 : le noyau du système. Il a un accès total à tout le matériel et à la mémoire.
• Ring 3 : les applications. Elles ne peuvent pas modifier directement le noyau et passent par des interfaces contrôlées.

Par défaut, un programme qui tourne en Ring 3 ne peut pas « descendre » en Ring 0. C’est ce qui empêche, par exemple, une application malveillante de modifier directement votre système.

Le Secure Boot, lui, intervient encore plus tôt : il s’assure que tous les composants critiques du démarrage (firmware, bootloader, noyau) sont signés et n’ont pas été modifiés. C’est ce qui garantit que le Ring 0 démarre dans un état sain, avant que quoi que ce soit d’autre ne s’exécute.

C’est ce principe qui permet à la plupart des systèmes d’exploitation et antivirus modernes de garantir un haut niveau d’intégrité.

La lutte anti-cheat devient du Ring 0

Comme je le disais en introduction, les tricheurs trouvent toujours des moyens plus inventifs pour déployer leurs outils :

• Drivers modifiés pour altérer l’affichage (ex. masquer la fumée d’une grenade).
• Périphériques externes simulant des actions humaines.
• Programmes qui lisent ou modifient directement la mémoire du jeu.

C’est le jeu classique du chat et de la souris en cybersécurité : chaque avancée d’un camp entraîne une contre-mesure de l’autre.

Ces dernières années, certains éditeurs de jeux ont choisi de descendre encore plus bas dans la pile système, en exploitant Secure Boot pour charger leur anti-cheat dès la phase de démarrage, avant même le noyau. Techniquement, on atteint alors un niveau comparable à celui des hyperviseurs (Ring -1), avec une visibilité totale sur le système.

À ce stade, l’anti-cheat se retrouve au même niveau technique que des solutions de sécurité avancées comme Bitdefender, SentinelOne ou Microsoft Defender ATP, qui s’installent également très tôt dans le processus de boot pour mieux détecter les menaces.

La différence ? Les antivirus et EDR sont conçus pour protéger tout le système, sont soumis à des audits, certifications et réglementations strictes… alors qu’un anti-cheat, lui, reste un logiciel propriétaire, non audité, dont l’objectif unique est de protéger un jeu. Pourtant, il obtient le même niveau de privilège qu’une solution de cybersécurité professionnelle.

La menace de la supply chain

Ces niveaux de privilèges élevés impliquent aussi de nouveaux risques.

Si je vous parle d'APT41, ca vous dit quelque chose ?

Il s'agit d'un groupe de hacker extrêmement prolifique qui à sévi il y a quelques années, et qui a réussi à s'infiltrer et compromettre certaines mises à jour de programmes, et notamment de jeux vidéos, comme par exemple :

• League of legends (Décembre 2014)
• Path of exile (Décembre 2014)
• FIFA Online 3 (Décembre 2014)
• Infestation (Juillet 2018)

Pour plus d'info sur ce groupe de hacker, je vous recommande l'excellente vidéo de Sylvqin qui couvre ce sujet.

Pourquoi je vous parle de ça ?

Parce qu’avec les modules anti-triche modernes, ce qui était autrefois un risque relativement identifiable et détectable devient une menace bien plus critique.

Un attaquant qui réussirait à se déployer via un anti-cheat aurait les mêmes privilèges qu’un EDR ou un antivirus : accès complet au système, possibilité de désactiver ou d’altérer les solutions de sécurité… tout en restant pratiquement invisible.

Menace sur la stabilité du système

L’autre problème majeur, selon moi, ce sont les risques que ces anti-cheats font peser sur la stabilité du système.

Vous vous souvenez peut-être de l’incident CrowdStrike de 2024 ? Une mise à jour défectueuse d’un composant de sécurité a provoqué, en quelques heures, des pannes massives à travers le monde.

2024 CrowdStrike-related IT outages - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

Le souci avec Secure Boot et les drivers chargés très tôt, c’est que la moindre erreur, même minime, peut littéralement empêcher votre système de démarrer. Et dans ce cas, même une réinstallation complète peut devenir compliquée : le système n’a même pas le temps de charger les outils nécessaires pour réparer le problème.

Et ce n’est pas tout : ces programmes peuvent aussi entrer en conflit entre eux. Il n’est pas rare qu’un anti-cheat empêche un autre de fonctionner, ou qu’il bloque le lancement d’un jeu concurrent.

A noter qu'un attaquant pourrait aussi exploiter ces outils pour juste rendre complétement HS des milliers, voire des millions d'ordinateurs!

Conclusion

L'escalade des solutions techniques des deux côtés mène aujourd'hui à un point qui me semble très dangereux.

On se retrouve avec des programmes arbitraires, créé par des entreprises dont la sécurité n'est pas le cœur de métier, qui peuvent opérer au même niveau de privilèges qu'un EDR!

Le secure boot doit rester une zone extrêmement restreinte où seules les applications les plus critiques ont le droit d'opérer, et je ne classifierais pas vraiment les anti-cheat dans cette catégorie...

Permettre à des jeux vidéos d'imposer ce genre de fonctionnement est pour moi une dérive dangereuse, tant en sécurité que du point de vue de la vie privée. En effet, sous prétexte de protéger les joueurs des raclures tricheurs, on a aujourd'hui des entreprises qui lisent, analysent et envoient des données en temps réel sur l'utilisation de votre ordinateur.

Mais quelles alternatives a-t-on vraiment ?

• Cloud Gaming pour mieux contrôler au niveau du système, mais pour moi ça signifie surtout une perte sur la propriété réelle d'un jeu
• Sandboxing au lancement du jeu pour l'isoler du système au maximum, au détriment des performances

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!

Comme souvent sur ce genre de billet, je tiens à rappeler que le contenu que vous trouverez ici l'est uniquement à des fins pédagogiques.

L'intrusion non autorisée dans un système d'information est passible d'amende et/ou d'emprisonnement.

Comprendre les attaques, c'est savoir comment les éviter. Dans ce billet, je vous propose de voir un modèle d'attaque réseau courant : l'ARP poisoning.

L'ARP, c'est quoi ?

Pour comprendre l'attaque, il faut déjà comprendre sur quoi elle repose.

Pour l'ARP, nous repartirons donc du modèle OSI, décrivant les différentes couches du réseau.

L'ARP est le lien entre la couche 2 et 3, c'est ce qui va permettre à un ordinateur ou serveur de convertir une adresse IP en adresse matérielle (MAC).

Pour fonctionner, l'ARP utilise un système de broadcast. Chaque périphérique sur le réseau envoie globalement à l'ensemble dudit réseau son adresse IP associée à son adresse matérielle.

Vous pouvez facilement accéder et modifier cette table avec la commande arp -a (que ce soit sous Linux ou Windows).

La faiblesse de ce protocole

Je pense que vous avez déjà localisé le point faible : chaque nœud envoie l'information, et rien ne permet de contrôler la véracité de celle-ci.

Ainsi, je peux très bien annoncer mon adresse MAC comme correspondant à l'IP du routeur.

Chaque nœud (ou les nœuds ciblés) sur mon réseau recevra donc cette information et mettre à jour sa table ARP avec la correspondance.

Comment se passe l'attaque?

Il y a un prérequis, être sur le même réseau que sa cible.

Ensuite l'idée consiste à se mettre entre la cible et le routeur. Cela permettra donc de lancer une attaque de type "Man in the middle" pour capturer tout le trafic réseau entre ma cible et le routeur.

Pour l'exemple que je vais prendre ci-dessous, je vais partir de mon propre réseau, et je vais me mettre entre mon PC et ma Livebox.

Pour ce faire, je vais donc envoyer deux informations différentes.

Depuis mon PC attaquant, je vais indiquer à ma livebox que je suis le PC de la victime.

À ma victime, je vais dire que je suis la livebox. De cette manière, cela me permet d'avoir les deux flux d'informations qui transit au travers de mon PC d'attaque, en me positionnant de la même manière qu'un proxy.

L'attaque en détail

Prérequis

Comme je l'ai décrit plus haut, je vais donc avoir besoin de plusieurs choses pour procéder à mon attaque :

• Un accès au même réseau que ma cible
• Un PC avec différents outils (que je décrirais plus bas)
• L'IP de ma cible, même si je peux m'en passer, comme nous le verrons

Dans le cas de ce billet, je vais utiliser deux machines virtuelles "Lab" :

• Mon attaquant sera une VM utilisant Kali Linux
• Ma cible sera un VM sous Windows 10

Détecter le PC Windows

Pour effectuer mon attaque, je vais utiliser le populaire bettercap.

Ce dernier va me fournir l'ensemble des outils dont j'ai besoin pour détecter les périphériques sur mon réseau et procéder à l'ARP poisoning.

Je vais donc le démarrer avec la commande ci-dessous :

bettercap -iface eth0

Bettercap fonctionne avec des modules, configurables et exécutables. Je ne rentrerais pas dans les détails des modules ici, et je vous invite à consulter la documentation associée pour plus de détails.

Si nécessaire vous pouvez utiliser la commande help pour voir les commandes et modules disponibles ainsi que leurs statuts.

Dans un premier temps, nous allons utiliser le module "net.probe".

Comme son nom l'indique, ce dernier va nous permettre de détecter les périphériques sur le réseau.

net.probe on
net.show

On retrouve bien ma cible ci-dessous, qui n'est autre que l'IP 192.168.109.130

Commençons à s'amuser

Maintenant nous allons lancer l'attaque sur la table ARP de la cible.

Avant de commencer, je vais juste capturer la table de ma cible.

Le plus important ici est l'IP 192.168.109.2 qui correspond à l'IP de mon routeur virtuel.

Depuis ma VM Kali, toujours dans bettercap, je vais donc passer à l'offensive!

set arp.spoof.fullduplex true          #Indique de lancer l'attaque sur la cible et sur le routeur
set arp.spoof.targets 192.168.109.130  #Indique l'IP de la cible
arp.spoof on                           #Lance l'attaque

La première ligne est importante, car elle va permettre de lancer directement l'attaque des deux côtés.

À noter que certains routeurs sont protégés contre les attaques ARP. Dans ce cas, nous ne verrons que les trames sortir de la cible, mais pas le retour, ce qui limite les attaques.

Si je regarde la table ARP de ma cible maintenant, nous verrons que l'IP du routeur n'est plus la même!

Au passage, on notera qu'elle a maintenant la même adresse MAC que ma VM Kali 192.168.109.129.

Maintenant je suis capable de voir le trafic entrant et sortant de ce PC avec un simple net.sniff on

Qu'est-ce que ça m'apporte à ce point ?

Arrivé là, je suis capable de capturer l'ensemble du trafic non chiffré sortant du PC de ma victime.

Cela signifie que je peux voir :

• Les appels en HTTP
• Les requêtes DNS non chiffrées
• Les requêtes SNI

C'est tout naze, on voit que le HTTP

Beaucoup diront que cela correspond à une faible partie du réseau. C'est vrai et faux à la fois.

Si je suis dans une entreprise, beaucoup considèrent qu'il n'est pas nécessaire de mettre du chiffrement pour les endpoints internes par exemple, cela permet donc de potentiellement capturer beaucoup de trafic.

De même savoir sur quel site un utilisateur va me permet potentiellement de cibler une attaque, que ce soit du phishing ou du social engineering.

Enfin, il faut voir cette partie comme une première étape, en effet, une fois que je suis positionné en man in the middle cela me permet aussi d'altérer le trafic pour modifier ce que voit ma victime, mais nous verrons ce point dans un autre billet!

En conclusion, méfiez-vous de TOUS les réseaux

Le but de ce billet est de rappeler qu'un attaquant n'est pas forcément externe, même dans votre réseau d'entreprise il est possible de faire pas mal de dégâts.

L'ARP spoofing fait partie des points qui sont normalement couverts par la plupart des routeurs d'entreprise, mais pas tous. Il est important de s'en protéger.

La plupart des routeurs grand public ne proposent pas de protections particulières à ce sujet, par exemple, je peux faire cette attaque sur ma Livebox.

Cela rappelle aussi l'importance de tout chiffrer sur le trafic sortant de votre PC, via un VPN par exemple, il existe aujourd'hui encore de très (trop) nombreux services communiquant en HTTP.

En entreprise, n'hésitez pas non plus à imposer le TLS partout, y compris en interne.

Si vous souhaitez en savoir plus sur ce qu'apporte un VPN, rendez-vous sur mon billet associé!

Un VPN protège-t-il réellement votre vie privée ?

Dernièrement, je vois de plus en plus de publicité indiquant que tel ou tel VPN protège votre vie privée. On m’a aussi posé plusieurs fois la question afin de comprendre si c’était vraiment le cas ou non. Aujourd’hui, j’ai donc décidé de vous parler de VPN.

TFerdinand.netTeddy FERDINAND

Je travaille sur des environnements AWS depuis plus de 6 ans maintenant. Que ce soit en tant qu'Ops, architecte, ou architecte sécurité, il y toujours une constante que je constate autour de moi : l'IAM d'AWS est très souvent mal utilisé.

Dans ce billet, je vous propose de faire un petit tour d'horizon des raisons probables.

Parce que la doc vous indique de mettre du wildcard

La documentation est censée être le pilier sur lequel s'appuyer. Toutefois, force est d'admettre que la documentation d'AWS est loin d'être un exemple en ce qui concerne l'IAM.

Bien que la firme prône le least privilege, beaucoup de ses documentations en sont très loin.

De mon point de vue, la documentation est censé montrer des exemples les plus sécurisés possible pour "pousser" les utilisateurs à adopter les bons réflexes. Force est d'admettre que ce n'est pas le cas.

Parce que les APIs sont inconsistantes

Principal souci du modèle d'AWS, qui fait que chaque équipe produit est autonome : L'inconsistance des API.

Les même actions ne correspondent pas forcément au même verbes API...

Ainsi la simple action de créer un tag peut avoir plusieurs nom différents en fonction des services, comme par exemple :

• elasticloadbalancing:addTags
• ec2:createTags
• ecr:tagResource

Mais comme ce serait trop simple, toutes les API n'ont pas forcément les mêmes type de cible.

Ainsi si je veux cibler des ressources en fonction de leurs tags, j'ai encore une fois des filtres différents :

• aws:ResourceTag/${TagKey}
• aws:TagKeys
• elasticmapreduce:ResourceTag/${TagKey}

Parce que le filtrage est inégal

Lorsqu'on met en place un modèle zero trust basé sur le least privilege, on va vouloir cloisonner au mieux les droits que l'on donne pour éviter toute action non désirée.

Maintenant on arrive au vrai problème.

En fonction des ressources, on pourra (ou non) filtrer correctement, mais pas forcément au même niveau.

Certaines ressources ont des ARN prévisibles, dans ce cas il est simple filtrer en amont (avant même que la moindre ressource soit créé).

D'autres fonctionne sur des identifiants internes créés par AWS, comme les security group par exemple.

Dans ce cas, il est parfois possible de filtrer sur la présence de certains tags, mais une fois de plus, pas tout le temps!

En effet, tous les services n'appliquent pas les tags de la même manière. Certains vont l'appliquer dès la création, d'autres après. Parfois tout se fait en un seul appel API, parfois en plusieurs...

Parce qu'il y a de multiples type de policies

J'aime à dire que l'IAM d'AWS est sans doute l'un des plus complet à ce jour. Toutefois, sa complétude vient aussi avec une complexité certaine : Le nombre de policies et les différentes couches qui s'appliquent à chaque évaluation.

• Commençons par le plus simple : les policy IAM "classiques", que l'on appelle aussi "Identity based policies", ce sont les politiques que tout le monde exploite directement lorsque vous vous connectez à AWS. Ce sont aussi ces dernières qui sont utilisées quand vous utilisez des roles AWS.
• Ensuite, il y a les "resource based policies", qui au contraire des précédentes sont directement attachées à un service, comme S3, SQS ou IAM (pour les trusts)
• Puis viennent les boundaries, ces policies sont attachées à des roles ou utilisateurs pour filtrer les droits, un peu comme un tamis.
• On pourrait aussi parler des SCP, qui englobent tout un compte ou une OU du service AWS Organization, pour appliquer des boundaries globales.
• il y a enfin des policies qui peuvent être crée à la connexion avec un utilisateur fédéré : les session policies

Cinq type des policies qui peuvent toutes être utlisées en même temps lorsque vous accédez à un service, cinq!

Je ne peux que comprendre ceux qui se perdent dans ces multiples niveaux d'abstraction.

Parce qu'il y a beaucoup de limitations

Comme tous les services d'AWS, l'IAM a ses propres limitations.

Par exemple, un role IAM ne peut pas avoir plus de 10 managed policies d'attachées, et chacune de ces policies ne peut pas dépasser 6144 bytes (sans les espaces/sauts de ligne).

Un role ou un utilisateur ne peut pas avoir plus d'une boundary attachées.

Ces limitations empêchent de pouvoir composer des roles ou utilisateurs de manière optimale car si l'on veut restreindre au maximum, on est obligé de recréer des policy pour chaque ressource!

De plus quand on veut pouvoir donner des accès console + CLI, on est parfois obligé de donner plus de droit que souhaité car sinon on empêche la console de fonctionner correctement.

Parce que même le support y perd son latin

Mon dernier point et non des moindre : le support lui même s'y perd!

j'ai déjà eu à contacter le support à de multiples reprises pour des soucis d'IAM, et force est d'admettre que très souvent le support tatône pour trouver une policy fonctionnelle ou comprendre d'où peuvent venir les blocages.

Entre l'inconsistance des API, des ressources, des filtres et la complexité de certaines policies lorsqu'on veut filtrer efficacement, c'est parfois compliqué de suivre le fil.

Comment améliorer les choses ?

Malgré tout les points que j'ai cité, il est toujours possible de faire "proprement" des policies (du moins du mieux possible), toutefois, ca demande du temps et de l'outillage.

Pour ma part, voici ce que j'utilise très (très) souvent :

• La documentation officielle de toutes les API, avec leurs filtres : Cette documentation est relativement bien tenue à jour et vous permet d'avoir déjà une bonne vision d'ensemble
• Le simulateur de policy d'AWS : qui vous permet de tester une policy sur une action particulière, très utile quand on veut filtrer sur des ARN ou tags par exemple.
• Des linter de policy, que ce soit celui intégré dans AWS Access Analyzer ou des outils tiers comme Parliament par exemple

Il faut garder en tête que l'IAM d'AWS reste complexe de part sa puissance. Pour ma part, même après des années à en faire quotidiennement, je suis très loin d'en maîtriser 100% de ses aspects...

Les certificats TLS font partie du quotidien pour n’importe qui manipule les technologies du web.

Mais saviez-vous que vos certificats peuvent trahir vos projets confidentiels, vos environnements non productifs ou la topologie de votre entreprise ?

Un besoin de transparence

Pour comprendre pourquoi vos certificats peuvent être un vecteur d’attaque, nous allons nous pencher sur le fonctionnement même d’un certificat TLS, du point de vue de votre navigateur.

Fonctionnement du TLS « classique »

...

La suite sur le blog de WeScale

Ç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.

Dans les deux premiers billets de cette série, nous avons vu comment créer notre bucket de base, configurer notre nom de domaine, et manipuler rapidement Hugo.

Dans ce dernier billet de la série, nous allons donc passer à l'étape manquante : le déploiement.

Automatiser le déploiement sur Scaleway

Créer un utilisateur API

Nous allons commencer par créer un utilisateur API sur la console Scaleway.

Pour cela, rendez-vous sur le menu en haut à droite, puis "Identifiants"

Cliquez ensuite sur "Générer une nouvelle clé API", puis donnez-lui un nom.

Copiez de suite les identifiants, il ne sera pas possible de les récupérer ensuite!

Préparer la clé dans le repository

Dans votre repository Github, rendez-vous dans "Settings", puis "Secrets"

Nous allons créer deux secrets :

• AWS_ACCESS_KEY_ID: qui porte la clé publique
• AWS_SECRET_ACCESS_KEY : qui porte la clé privée

Ces secrets ne sont pas récupérables directement, à part par votre pipeline de déploiement.

Préparer la configuration S3 pour Scaleway

Scaleway exploitant le standard S3 d'AWS, nous allons utiliser la ligne de commande d'Amazon pour pousser sur S3.

Toutefois, nous aurons besoin de configurer le client pour qu'il pointe vers scaleway au lieu d'AWS.

La configuration nécessaire est décrite sur la documentation officielle de Scaleway :

Using Object Storage with the AWS-CLI

This page explains how to use Scaleway Object Storage with AWS-CLI.

Scaleway Documentation

Pour ma part, j'ai donc créé un répertoire aws à la racine de mon repository, qui a simplement un fichier config avec le contenu suivant :

[plugins]
cli_legacy_plugin_path = /home/runner/.local/lib/python3.8/site-packages
endpoint = awscli_plugin_endpoint

[default]
region = fr-par
s3 =
  endpoint_url = https://s3.fr-par.scw.cloud
  signature_version = s3v4
  max_concurrent_requests = 3
  max_queue_size = 1000
  multipart_threshold = 5000MB
  multipart_chunksize = 1000MB
s3api =
  endpoint_url = https://s3.fr-par.scw.cloud
retries =
  max_attempts = 20

Préparer notre pipeline Github actions

Enfin, nous allons préparer un fichier de configuration pour notre pipeline, c'est ce dernier qui se chargera de livrer chaque modification sur notre bucket.

Pour ce faire, nous allons créer le fichier .github/workflows/deploy/yml, dans lequel nous allons mettre le contenu suivant :

name: CI
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  workflow_dispatch:
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Install Hugo engine
        run: sudo apt update && sudo apt install -y hugo unzip python3-pip

      - name: Install Aws CLI v2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "/tmp/awscliv2.zip"
          cd /tmp
          unzip awscliv2.zip
          sudo ./aws/install --update
          cd -

      - name: Install awscli_plugin_endpoint
        run: pip3 install awscli_plugin_endpoint && pip3 show awscli_plugin_endpoint

      - name: copy ScaleWay AWS CLI configuration
        run: |
          mkdir ~/.aws
          cp ./aws/config ~/.aws/config

      - name: Compile items
        run: hugo -D

      - name: Push to Scaleway storage
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: /usr/local/bin/aws s3 sync --delete ./public/ s3://demo-hugo.tferdinand.net/

Ce fichier indique plusieurs informations :

• Nous ne voulons lancer le pipeline que lors d'un commit sur master, ou le merge d'une branche sur le master
• Nous allons utiliser une image docker Ubuntu pour effectuer le déploiement
• Nous avons un déploiement en plusieurs étapes

Concernant ces étapes nous avons donc :

• Le checkout du code : nous indiquons que nous voulons que le code de notre repository soit rapatrié (c'est mieux pour l'utiliser)
• Ensuite, nous installons via apt : Hugo, unzip, et pip. Ces derniers sont peut être déjà présents, mais ça ne coûte rien de s'en assurer
• Après, nous déployons le client AWS V2, comme le point précédent, il est peut être déjà là, mais ça ne coûte rien.
• Nous installons ensuite le plug-in nécessaire pour surcharger le endpoint S3 vers Scaleway
• Nous déployons notre configuration AWS
• Nous lançons la compilation du site avec Hugo, il nous générera les fichiers HTML statiques dans le répertoire "public"
• Enfin, nous poussons le site sur S3, l'option --delete permettant de supprimer les fichiers qui ne sont éventuellement plus présents

Let's rock!

Maintenant que tout est prêt, il est temps de faire un gros push vers Github.

Si vous allez sur l'interface, dans l'onglet "actions" vous devriez voir votre pipeline tourner.

En quelques minutes, il devrait avoir fini :

Et si vous allez sur votre bucket sur Scaleway, vos objets sont bien présents :

Enfin, si nous retournons sur notre record DNS que nous avions créé plus tôt, nous avons bien notre site qui s'affiche :

En conclusion

Hugo est un outil puissant

Dans ce billet, je n'ai fait que survoler Hugo. Si vous voulez en savoir plus, je vous encourage vivement à visiter la documentation du projet, qui a le mérite d'être très accessible.

Hugo Documentation

Hugo is the world’s fastest static website engine. It’s written in Go (aka Golang) and developed by bep, spf13 and friends.

News

Scaleway vous permet de commencer un blog sans prendre de risque

Le stockage objet de scaleway est adapté si vous voulez commencer un blog sans prendre de risque.

En effet, il ne coûte rien, et vous permet d'avoir un service de qualité sans avoir besoin de passer du temps à le maintenir en fonctionnement.

De plus, cela vous permet d'héberger vos données en France, par un acteur français!

Github simplifie les choses

J'ai fait le choix de Github pour ce billet, mais j'aurais pu aller jusqu'au Github pages, qui permettent aussi d'héberger du contenu statique. J'ai choisi de mettre Scaleway comme point final, car je voulais montrer qu'on pouvait aussi héberger en France sans avoir plus de difficultés.

Ces billets sont une base

Comme je l'ai dit plusieurs fois, ces billets sont une simple base, beaucoup de choses sont améliorables, et beaucoup de chemins alternatifs sont possibles.

Le but est simplement de montrer une solution, fonctionnelle de bout en bout.

N'hésitez pas à réagir dans les commentaires si vous voyez des points à améliorer!

Dans mon billet précédent, nous avons créer le socle nécessaire pour recevoir notre code et notre site terminé.

Si vous ne l'avez pas lu, vous pouvez le retrouver ici:

Un blog Hugo sur Scaleway avec Github et Github actions - Partie 1/3

Héberger un blog ne demande pas forcément une énorme infrastructure et beaucoup de moyens. Il est possible de créer un blog simplement pour quelques euros par an (et encore). Il y a quelques mois, j’avais écrit un billet indiquant l’importance de publier son contenu “chez soi”, que vous pouvez retro…

TFerdinand.netTeddy FERDINAND

Cette semaine, nous allons passer à Hugo. Nous allons voir comment l'utiliser de manière très basique pour créer notre blog, et nous créerons le repository Github qui hébergera le code de notre blog.

Passons à Hugo

Créer un repository Github

Pour ce billet, j'ai choisi d'héberger le contenu sur Github, rien n'empêche de l'héberger ailleurs.

L'intérêt de Github est multiple :

• Hugo repose sur des fichiers "descriptifs" très légers
• Github permet d'historiser
• Github permet de sauvegarder
• C'est simple de gérer les accès pour gérer un blog à plusieurs par exemple
• Il est possible d'avoir un process de revue (automatisé ou non) avant la publication

Donc, nous allons donc créer un repository Github, que vous pouvez mettre en public ou privé selon ce que vous préférez.

Ce repository portera donc notre "code Hugo" ainsi que le pipeline de déploiement, puisque comme je l'ai dit plus haut, j'utiliserai Github actions pour le déploiement et les mises à jour de mon blog.

Initialiser mon blog

Sur mon ordinateur, je vais donc cloner mon repository tout beau tout neuf, puis je vais installer Hugo.

Pour cela, je vous invite à consulter la documentation officielle à ce propos, qui vous permettra de choisir la solution la plus adaptée à votre besoin.

Install Hugo

Install Hugo on macOS, Windows, Linux, OpenBSD, FreeBSD, and on any machine where the Go compiler tool chain can run.

News

Une fois le blog installé, je vais donc initialiser mon blog, depuis mon répertoire Github, je vais donc lancer :

hugo new site --force .

Le --force est nécessaire, car nous ne sommes pas forcément dans un répertoire vide (si vous avez choisi de mettre un readme par exemple).

À ce point, vous avez normalement un certain nombre de fichiers qui se sont créés dans votre répertoire.

ted@kali:/home/ted/dev/hugo-demo# ls -l
total 0
drwxrwxrwx 1 ted ted 512 Dec 22 17:17 archetypes
drwxrwxrwx 1 ted ted 512 Dec 22 19:23 aws
-rwxrwxrwx 1 ted ted 123 Dec 22 17:34 config.toml
drwxrwxrwx 1 ted ted 512 Dec 22 17:18 content
drwxrwxrwx 1 ted ted 512 Dec 22 17:17 data
drwxrwxrwx 1 ted ted 512 Dec 22 17:17 layouts
drwxrwxrwx 1 ted ted 512 Dec 22 17:17 public
-rwxrwxrwx 1 ted ted  11 Dec 22 19:11 README.md
drwxrwxrwx 1 ted ted 512 Dec 22 17:17 resources
drwxrwxrwx 1 ted ted 512 Dec 22 17:17 static
drwxrwxrwx 1 ted ted 512 Dec 22 19:47 themes

À noter qu'Hugo est un moteur, il vient nativement sans aucun theming.

Nous allons donc en ajouter un. Pour cette démo, j'ai choisi un thème très basique, listed, disponible sur Github.

De nombreux autres thèmes sont disponibles via des sites tiers comme Jamstack par exemple :

Hugo Themes

Browse Hugo themes, starters and templates.

Jamstack Themes

Donc, nous allons cloner notre thème, puis l'activer :

git submodule add https://github.com/ronv/listed.git themes/listed
echo theme = \"listed\" >> config.toml

Ensuite, je vous invite à modifier le fichier config.toml à la racine pour renseigner les informations qui vous correspondent (notamment l'URL racine du site).

À titre d'exemple voici le mien :

baseURL = "https://demo-hugo.tferdinand.net/"
languageCode = "fr-FR"
title = "Hugo Demo - TFerdinand.net"
theme = "listed"

Créer notre premier billet

Si l'on fait un blog, c'est pour avoir du contenu. Nous allons donc de suite créer un premier billet avec une simple commande :

 hugo new posts/my-first-post.md

Avec cette commande, nous indiquons que nous allons créer un post qui s'appellera "my-first-post".

Vous noterez l'extension : Hugo fonctionne avec des posts écrits en markdown. Si vous n'êtes pas à l'aise avec ce templating, il existe de nombreuse "cheat sheet" pour vous aider, comme :

Markdown Cheat Sheet | Markdown Guide

A quick reference to the Markdown syntax.

Markdown Guide

Ensuite, vous pouvez éditer votre post, qui se trouvera dans ./content/posts/my-first-post.md

Voici par exemple les informations que j'y ai mises.

À noter que le premier bloc entre les tirets en haut correspond aux métadatas de votre billet.

Avant de fermer votre éditeur, n'oublier pas de changer la variable draft de true à false, sans quoi votre billet ne sera pas publié.

---
title: "My First Post"
date: 2021-12-22T17:23:34+01:00
draft: false
toc: false
images:
tags:
  - untagged
---

Hello friend!

As you can see, we use **markdown** to create a simple blog

```python
#!/usr/bin/env python3
# We can use every markdown blocks

works = True
if works:
        print "You're the best!"
```

Vous pouvez tester le rendu en lançant la commande suivante :

hugo server -D

qui devrait vous donner le résultat suivant :

ted@kali:/home/ted/dev/hugo-demo# hugo server -D

                   | EN
+------------------+----+
  Pages            | 12
  Paginator pages  |  0
  Non-page files   |  0
  Static files     |  3
  Processed images |  0
  Aliases          |  4
  Sitemaps         |  1
  Cleaned          |  0

Total in 75 ms
Watching for changes in /mnt/d/dev/hugo-demo/{content,data,layouts,static,themes}
Watching for config changes in /mnt/d/dev/hugo-demo/config.toml, /mnt/d/dev/hugo-demo/themes/listed/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

À partir de là, vous pouvez vous rendre sur http://127.0.0.1:1313 pour voir votre blog tourner.

Maintenant, c'est bien joli, mais vous n'allez pas faire se connecter les utilisateurs sur votre PC!

A suivre au prochain épisode

Dans les deux premiers billets, nous avons vu comment créer notre bucket qui servira notre site, ainsi que le domaine associé, puis nous avons commencé à manipuler Hugo.

Dans le billet final, nous mettrons en place le nécessaire pour automatiser le déploiement et avoir un blog en haute disponibilité, automatisé, sauvegardé à moindre coût.

Rendez-vous pour le grand final!

Héberger un blog ne demande pas forcément une énorme infrastructure et beaucoup de moyens. Il est possible de créer un blog simplement pour quelques euros par an (et encore).

Il y a quelques mois, j'avais écrit un billet indiquant l'importance de publier son contenu "chez soi", que vous pouvez retrouver ci-dessous.

Pourquoi c’est important de publier chez soi

Je vois nombre de personnes que je suis publier des contenus sur les espaces prévus sur les réseaux sociaux, ou sur des plateformes comme YouTube, TikTok, etc. Je ne pense pas que ce soit forcément une bonne idée : plutôt que de mettre en avant votre contenu à coup de “like”

TFerdinand.netTeddy FERDINAND

Suite à ce dernier, beaucoup m'ont contacté pour me demander des exemples concrets de ce que j'entendais par là.

Aujourd'hui, je vais donc vous présenter un modèle, que vous pouvez facilement modifier ou faire évoluer pour héberger votre contenu à moindre coût. Tout en prenant en compte la haute disponibilité, les sauvegardes et le déploiement.

La cible

Je vais partir sur une cible assez simple.

Je veux pouvoir éditer mon blog depuis mon PC, pousser le code sur Github, et qu'il soit publier en quelques minutes.

De manière très synthétique, voici la cible.

Le seul prérequis est d'avoir un nom de domaine (et on peut s'en passer si on le souhaite).

Certains domaines ne coûtent presque rien, par exemple le ".ovh" ne coute que 3€ HT par an!

Hugo, c'est quoi ?

Hugo est un moteur de création de sites, open source, générant des fichiers statiques. L'intérêt premier est de ne pas nécessiter de compilation à la volée comme avec des langages interprétés (Php, Node, Python, etc.), et il n'a donc pas besoin de base de données.

Dans le cas d'un blog, c'est un modèle adapté, car nous avons du contenu qui n'a pas besoin de bouger énormément au jour le jour.

Pour plus d'information, je vous invite à vous rendre sur le site du projet !

The world’s fastest framework for building websites

The world’s fastest framework for building websites

News

Let's go

Maintenant que vous avez notre nom de domaine, on va commencer à préparer le socle qui va recevoir notre site.

Pour ce billet, j'ai fait le choix de le faire manuellement, mais libre à vous de l'automatiser si vous le souhaitez!

À noter que le mode d'hébergement que nous allons utiliser ne sait pas gérer le chiffrement TLS avec votre nom de domaine.

Pour cela il faut soit :

• Que vous mettiez un reverse proxy devant
• Que vous passiez par des solutions qui vont faire du proxy, comme Cloudflare (que j'utiliserais dans ce billet)

Première étape : Créer un compte sur Scaleway

Pour cela, il vous faut ouvrir un compte sur Scaleway. Ce compte est gratuit. Scaleway est un cloud provider d'Illiad. Pas d'inquiétude, une carte bleue vous sera demandée, mais vous n'aurez aucune facture, je peux vous l'attester :

Scaleway Elements Console

Begin your Journey in the Public Cloud and start scaling with us

Seconde étape : Créer un bucket de stockage sur Scaleway

Ensuite, nous allons utiliser la solution de stockage d'objet de Scaleway.

Pourquoi cette solution?

• 75Go de stockage et transfert offert tous les mois, sans limites de durée
• Compatible S3 (nous en aurons besoin ensuite)
• Taux de disponibilité à 99.99% (ce qui correspond à une indisponibilité maximale de 5 min par mois)
• Possibilité d'héberger votre contenu en France
• Cloud souverain

À noter qu'un stockage d'objet est prévu pour stocker des fichiers statiques, qui peuvent être téléchargés directement. Nous ne pouvons pas manipuler les fichiers en direct comme sur un disque dur.

Nous allons donc cliquer sur "Object storage" dans le menu "Stockage" du menu latéral gauche. Ensuite, nous allons cliquer sur le "+" en haut à droite pour créer un nouveau bucket.

Vous devriez arriver sur un masque similaire à celui-ci :

Dans mon cas, vous pouvez voir qu'il s'agit de "demo-hugo.tferdinand.net" que j'ai créé pour l'occasion. Vous pouvez choisir la région que vous souhaitez, pour ma part, j'ai pris la France. Pour la visibilité du bucket, vous pouvez laisser en privé, nous reviendrons indirectement dessus par la suite.

Une fois le bucket créé, cliquez sur son nom, puis allez dans l'onglet "Réglages du bucket".

La partie qui nous intéresse ici est le "bucket website". Cette fonctionnalité va nous permettre de créer un serveur web distribuant des fichiers statiques.

Nous allons donc activer la fonctionnalité, et indiquer les paramètres suivants :

• Nom du fichier d'index : index.html
• Nom du fichier d'erreur : 404.hmtl

Vous pouvez ensuite cliquer sur "enregistrer la configuration"

Troisième étape : configurer Cloudflare

Cloudflare est aussi un service gratuit pour une utilisation non commerciale, car nous n'avons pas forcément besoin de ses fonctionnalités avancées.

Cloudflare est d'ailleurs devant mon serveur, et vous l'utilisez actuellement!

Nous allons donc récupérer le nom de domaine de notre bucket, dont nous aurons besoin.

Ensuite, depuis l'interface de Cloudflare, nous allons créer un record DNS CNAME qui pointera vers ce bucket.

Attention, si on veut avoir du TLS, il faut bien choisir l'option "Proxied" sur Cloudflare, qui permet de surcroit d'exploiter le cache de ce CDN.

Arriver à cette étape, vous pouvez vous rendre sur votre record DNS, et si tout va bien, vous obtiendrez une jolie erreur 404.

Pas d'inquiétude, c'est normal. Actuellement, nous avons un hébergement, mais aucune donnée dessus!

To be continued

Comme je vous l'ai indiqué en préambule, ce billet est le premier d'une série de trois.

Rendez-vous au prochain billet pour dans lequel nous commencerons à manipuler légèrement Hugo et nous créerons le repository Github qui hébergera notre solution.

Il y a quelques semaines, j'ai reçu Carl Chenet, créateur (notamment) du journal du hacker.

J'en ai donc profité pour échanger avec lui autour de sujets qu'il connait bien : le télétravail et l'open source.

Pour la première fois sur ce blog, vous pouvez retrouver cette interview dans 3 formats :

• En vidéo, via le lien Youtube, ou sur mon serveur Peertube
• En podcast, sur Spotify, Deezer ou Amazon Music
• En transcription texte, ci dessous

Bonjour à toi, Carl, ça me fait plaisir d’échanger avec toi pour cette interview. Dans un premier temps, je vais te laisser te présenter.

Dans la vie je suis freelance, architecte de systèmes informatiques, une branche que tu connais bien, à mon compte depuis 2012. J’ai une activité assez importante dans l’open source, dans lequel je suis investi depuis 2010, voire un peu avant même.

Depuis quelques années, j’ai pris un virage un peu différent dans l’entrepreneuriat dans lequel je lance différents projets, qui se recoupent bien l’open source et l’entrepreneuriat, car beaucoup de choses se croisent.

J’ai différents projets :

• J’ai créé un agrégateur de liens web qui s’appelle le journal du hacker
• J’ai créé une newsletter qui se base sur le journal du hacker qui s’appelle le courrier du hacker qui a atteint les 4000 abonnés, pour 187 numéros, je crois.
• Un projet qui fait le lien entre l’entrepreneuriat et l’open source, qui s’appelle Linuxjobs.fr qui est un site d’emploi pour les professionnels de l’open source
• Le petit dernier : lesnewsletters.com, un site qui vise les créateurs de newsletter francophone afin de les aider à faire connaître et monétiser leurs newsletters

Tout ça en parallèle de mon activité de freelance, j’essaie de créer que des projets qui tournent seuls en majorité ou en grande partie.

Effectivement, je t’ai connu grâce au journal du hacker personnellement. Du coup, sans transition : Le journal du hacker, le courrier du hacker, linuxjobs, lesnewsletters, ça fait beaucoup de projets. D’où te vient cette volonté de partager toujours plus de connaissance avec le plus grand monde ? [Même si beaucoup de choses viennent de l’extérieur, comme tu l’as dit, ce sont en grosse partie des agrégateurs.]

C’est une bonne question ! Je pense que quand j’ai commencé au début dans l’open source, à la fin de mes études en informatique, j’avais déjà évolué dans le monde de l’open source, en particulier dans le monde de Linux. Et puis peu à peu dans le monde des distributions GNU Linux, et en particulier de Debian.

Il y avait donc ce projet, Debian, déjà très connu à l’époque [dans les années 2008-2010], qui me faisait envie. J’avais aussi de me prouver à moi-même que j’étais capable d’intégrer un projet open source d’importance. C’était pour me le prouver à moi-même, mais aussi prouver aux autres que je n’avais pas fait des études en informatique pour rien [rires], et que j’allais pouvoir apporter une pierre à l’édifice tout en construisant ma carrière professionnelle.

J’ai commencé, au tout début, sur un outil de traduction de KDE. J’aidais à développer la partie française, pour traduire ce qui était dans les logiciels de KDE. J’ai rapidement mis le pied à l’étrier comme ça. Mais rapidement, ce n’était pas assez technique, j’avais envie de partir sur quelque chose de beaucoup plus technique et donc je me suis aventuré dans le monde de la distribution Debian.

J’ai commencé par corrigé des petits bugs qui sont dans les programmes qu’on installe par défaut dans Debian, puis peu à peu, l’investissement a grandi. J’ai commencé à gérer mes premiers paquets, à arriver sur des paquets beaucoup plus lourds comme virtualenv et pip qui sont des outils pour le monde Python, que je connaissais bien aussi. J’ai développé une activité dans la communauté Python à côté de ça. Ça a été assez rapidement après mes études quelque chose que j’ai essayé de consolider.

Dans le même temps, j’ai écrit 56 articles pour GNU Linux magasine France (GLMF), qui est le principal magasine public du logiciel libre et de l’open source francophone (magasine papier).

Mon blog aussi, j’ai créé un blog très rapidement, qui a eu pas mal de succès dans les années 2012-2015.

Une aventure pour faire progresser le logiciel libre, l’open source, en tirer quelque chose que je pouvais partager de ma part. Je voulais me sentir utile, progresser techniquement parce que les apports de travailler avec les autres gens sont énormes. C’est le background technique qui s’est posé à moi.

J’ai eu ensuite un virage assez différent, une fois que je me suis prouvé ça, on avance assez rapidement dans le temps, on est en 2012-2015. J’ai commencé à avoir fait le tour, je suis devenu développeur Debian officiel. Ça veut dire que tu es reconnu par tes pairs, qui te propose puis les contributeurs confirment qu’ils sont d’accord pour que tu deviennes développeur Debian. Ça faisait déjà 4 ans que j’étais dans le projet. J’avais envie de voir et proposer autre chose.

Il ne faut pas se le cacher non plus, il y avait des raisons financières : sur l’open source tu peux passer beaucoup de temps à travailler pour les autres, à fournir de la valeur à la communauté, et au bout d’un moment j’avais envie de générer un peu d’argent sur un projet qui ne soit pas lié au salariat [j’étais encore salarié à l’époque].

J’ai commencé par un premier projet : Linuxjobs.fr, un site d’emploi que j’ai mis en place qui me permettait de faire le lien entre la communauté open source et l’entrepreneuriat.

À côté de ça, j’ai d’autres projets liés à l’open source également : le journal du hacker, un agrégateur de lien, sur lesquels les gens proposent des liens, et les liens qui ont le plus de succès se retrouvent sur la première page et sont le plus mis en avant.

Je suis parti sur une idée à la base de quelque chose qui ressemblait au site hacker news, qui est un gros site américain du même genre, en me disant "Ça n’existe pas en France, donc il faut que l’on fasse quelque chose à ce niveau-là".

On voit le début du virage entre l’entrepreneuriat et l’open source tout simplement.

J’ai rencontré assez rapidement mon premier associé, cascador [ il aime bien qu’on utilise uniquement son pseudo, alors je n’utiliserais que son pseudo], c’est quelqu’un que je considère vraiment comme le cofondateur, qui m’a soutenu dans le premier élan, qui a travaillé autant que moi sur le projet et qui nous a permis faire grandir ce projet, de le faire connaître, et d’arriver aujourd’hui à plusieurs milliers d’utilisateurs réguliers, avec plusieurs centaines de personnes qui postent des liens régulièrement. Et un noyau dur, comme tous les projets du logiciel libre, d’une dizaine, une vingtaine, une trentaine de personnes qui interviennent très souvent.

Je pense que c’est le succès le plus visible d’un de mes projets que j’ai eu à l’époque. Les gens ont commencé à voir le travail qui était fourni, en direction de l’open source, mais un outil qui était donné à disposition des gens, moins communautaire, moins "confidentiel" que le projet Debian où les gens sont peu connus.

[Teddy : Effectivement, ce n’est pas le même public, je pense. Sur le projet Debian, tu as un public qui est beaucoup plus initié à la technique que le journal du hacker. Sur le journal du hacker, tout le monde peut poster, proposer des choses, mais profiter aussi des liens qu’il y a dessus, je l’utilise moi-même pour ma veille technologique par exemple]

C’est l’envie que j’avais ! J’avais envie de sortir un peu de la technique, d’avoir un public plus large. J’ai un blog depuis quasiment le début. J’écrivais assez souvent sur LinuxFr, principal site francophone du logiciel libre et l’open source. J’ai toujours essayé de partager un peu. C’est vrai qu’on est dans une niche technique, mais je ressentais le cloisonnement qui pouvait être limitant pour notre communauté, et j’ai essayé d’ouvrir un peu ça avec le journal du hacker.

C’était vraiment l’approche d’un projet utilisable par le plus grand nombre.

Ensuite, le projet intéressant, je pense, qui découle du premier : comme j’ai mis un outil à disposition de la communauté, j’ai voulu pousser des gens à utiliser cet outil, et dans cette démarche, comme on est quasiment en open data on peut dire [on peut récupérer la base de données du journal du hacker et faire des projets tiers avec], et comme je voulais donner l’exemple sur ce type d’initiative, j’ai créé une newsletter qui chaque semaine résumé les meilleurs liens du journal du hacker et que j’ai nommé le courrier du hacker. Cette newsletter est indépendante, car je ne voulais pas mélanger les deux projets, mais elle s’appuie très fortement sur la base de données et tout le travail fourni par, comme toi par exemple, les créateurs de bons billets de blog, qui reçoivent des critiques positives, qui sont sur la première page du journal du hacker.

Je voulais continuer à mettre en avant ce travail de la communauté francophone, des créateurs de contenus, des sociétés, des individus qui créent ce contenu que je trouve excellent, et ça me permettait au travers de cette newsletter de remettre une couche auprès d’un public qui pouvait être différent de celui du journal du hacker.

Le journal du hacker, c’est un agrégateur, il faut aller tous les jours sur le site, l’investissement est différent. Donc le courrier du hacker, cette newsletter que j’envoie le vendredi le plus souvent, permet aux gens d’analyser un peu ce qui s’est passé. Et comme ce n’est pas email, tu peux le lire dans le train, de manière asynchrone, et ça marche bien. La courbe des abonnés a grandi assez rapidement.

Le projet est lancé depuis 3 ans maintenant, et cette année, on a franchi le cap des 3000 abonnés, c’est une recette qui ne change pas : toujours fournir les 18-20 meilleurs liens de la semaine passée, et elle continue de marcher, le nombre d’abonnés continue de grandir, et ça participe encore de sortir de cette niche technique et de partager au plus grand nombre ce que font les créateurs de la communauté logiciel libre et open source francophone.

Comme tu le disais, j’utilise beaucoup le journal du hacker, vu que je squatte régulièrement la première page [rire]. J’utilise peu les autres projets, mais je pense que ce sont des projets qui permettent de propager la connaissance au plus grand nombre, à partager cette connaissance, à l’apporter à tous, donc déjà je te remercie pour ça ! Tu as abordé un point qui est très intéressant : tu as dit que tu étais contributeur actif au projet Debian. C’est un point qui m’intéresse beaucoup, et je voulais savoir : ça fait quoi, concrètement, de contribuer à un projet open source de cette envergure ?

Alors c’est une aventure un peu en standby tout de même. Je suis assez loin de Debian aujourd’hui, je suis plus dans l’entrepreneuriat, mais on va dire qu’autour de 2012, j’étais assez investi.

Ça a commencé, comme je le disais au début, de manière assez triviale : j’ai commencé à apporter quelques correctement de bug, à parler avec les gens. C’était aussi pour moi la découverte de ce qu’on appelle aujourd’hui le télétravail : donc j’étais chez moi, j’envoyais des mails, je discutais en direct avec d’autres personnes qui étaient à l’étranger.

On échangeait de manière complètement asynchrone, tout ça en contribuant au projet Debian : le faire grandir, le faire évoluer, rendre disponible ce que les gens veulent trouver dans le projet Debian. C’était assez passionnant.

Je n’ai pas vu passer la première année, j’étais à cout de 4 heures par soir tous les soirs en rentrant du travail. C’était facile j’étais encore chez ma mère, donc c’est elle qui faisait à manger [rires] !

Au bout d’un an, j’avais un mentor, quelqu’un avec qui je travaillais régulièrement, un Italien, Sandro Tosi, que je salue.

Donc je lui dis "ça fait un an que je bosse, tu vas peut-être me sponsoriser pour que je sois développeur Debian", et là il m’a dit "Ah non, tu ne peux pas", puisqu’à l’époque seuls les gens qui géraient des paquets pouvaient devenir développeurs Debian. Ce n’est plus le cas aujourd’hui, même des gens non techniques peuvent l’être : des gens qui font des conférences, qui s’investissent dans la communauté, qui promeuvent l’accessibilité, peuvent être reconnus en tant que "developpeur Debian", et avoir le même statut.

À l’époque, ce n’était pas le cas, et là je me suis dit "ça fait un an que j’écris des programmes Python pour Debian et je ne peux pas être développeur Debian".

Donc rebelote, j’ai commencé à gérer des paquets Debian. Et qui travaille avec Debian sait l’énorme machinerie des paquets Debian qui est extrêmement fiable et présente dans la distribution Debian, et je m’y suis collé, j’ai représenté un an après ma proposition.

Ça a pris un peu de temps, parce qu’il a fallu que je trouve un sponsor. Quelqu’un acceptait de sponsoriser mon entrée. Mon sponsor officiel l’avait déjà fait, et ne souhaitait plus le faire.

Il y a eu beaucoup d’humains à cette période, et je crois que je suis devenu développeur Debian au bout de 3 ou 4 ans, ça ne s’est pas fait du jour au lendemain.

C’est fait pour, clairement, on ne te donne pas les clés des archives des paquets Debian comme ça. Il faut montrer patte blanche, c’est un très gros projet, ils doivent être à plus de 1000 développeurs officiels aujourd’hui [NDLR 1022 à l’heure de l’écriture].

Ça fait 1000 personnes qui peuvent jouer avec les archives. Déposer des paquets dans les archives, évidemment, c’est cloisonné, il y a des sécurités. C’est la première reconnaissance par les pairs, comme j’en parlais tout à l’heure.

Quand tu reçois ton email avec tes différents credentials et identifiants, les liens vers ta boite mail Debian, tu te sens reconnu, d’appartenir à un projet auquel tu contribues de manière quotidienne.

C’est un sentiment assez incroyable. C’est l’un des plus gros projets logiciels avec le noyau Linux. Je crois c’est parmi les plus gros en termes de contributeurs. J’étais fier et heureux de travailler et j’ai continué à contribuer assez longtemps sur ces sujets.

Je suis toujours développeur Debian officiel, mais je suis un peu plus en retrait de la contribution.

Effectivement, je pense que les mentalités ont un peu changé pour mettre en avant les contributions dans l’open source, moi même je suis "Traefik ambassador", à une échelle beaucoup plus petite, celle du projet Traefik, et je sais qu’aujourd’hui beaucoup de projets essaient de pousser vers la contribution, mais pas forcément la contribution purement technique : parler du projet, le documenter, en parler en conférence permet aussi d’être mis en avant. Après de ce que tu dis, c’est tout de même quelque chose d’assez incroyable, et on retrouve la rigueur qui fait la réputation de Debian dans les process que tu décris, même en interne.

Je continue de suivre le projet Debian, même sur les listes privées de Debian, et on voit qu’un projet d’une telle envergure doit se protéger au niveau humain.

Parce qu’évidemment sur 1000, tout le monde n’est pas ou plus forcément d’accord avec ce qu’il se passe ou avec la majorité des gens, tu as des gens qui craquent. Et comme ils ont été développeurs Debian, ils ont un pouvoir de nuisance qui est certain.

Une fois que tu es développeur Debian, tu as accès à une bonne partie de l’infrastructure. Tu as uniquement les Debian SysAdmin qui possèdent réellement les clés de tous les serveurs, mais tu n’en es pas loin, tu peux te connecter en utilisateur normal sur une grande partie de l’infrastructure. Ce qui est déjà une porte ouverte à beaucoup de choses.

La machine du projet Debian a appris à se protéger, mais ça reste beaucoup d’humain, tu vois que les "core developpers" de Debian sont réduits, je pense qu’il n’y a pas plus d’une cinquantaine de personnes où tu n’envoies pas un email sans les voir réagir. Ça reste beaucoup d’humains malgré la taille du projet, et bien évidemment des systèmes de protection, de CICD, de moyens techniques pour protéger le projet.

En parlant des projets open source, tu fais partie des gens qui militent pour que l’open source se développe, pour que l’open source soit utilisée le maximum possible. Est-ce que tu penses qu’aujourd’hui tous les besoins peuvent être adressés par l’open source ?

C’est une bonne question ! Je ne connais pas tous les besoins, donc ça va être dur de répondre.

En tout cas dans ma carrière, j’ai croisé beaucoup d’utilisation, et Debian est utilisé dans des domaines spécifiques : l’administration système, l’infrastructure système par exemple.

L’open source marche très bien, je dirais même qu’elle a gagné, avec notamment les offres cloud qui sont en grande majorité des serveurs Linux. Donc dans l’infrastructure, c’est clairement un domaine ou l’open source s’est bien développé.

Dans l’embarqué, c’est des systèmes dérivés de Linux, donc basés sur de l’open source, même si parfois ça peut dériver comme avec Android.

La sécurité est un domaine que je connais moins bien, mais je vois beaucoup d’outils open source, ou en tout cas d’outils qui sont basés sur de l’open source à la base, qui sont transformés, modifiés.

Est-ce que des domaines échappent complètement à l’open source ? Je n’en ai pas l’impression. Un des domaines sur lesquels j’ai écrit des billets de blog récemment, c’est le rachat par Microsoft de Github : on voit que quelque part, on voit une espèce d’aveu que le modèle open source est en passe de devenir le modèle dominant.

Après qu’il couvre tous les besoins, c’est une très bonne question. Connaissant la diversité du monde, surement pas, il y a surement des besoins pour lesquels ce n’est pas nécessaire, mais je pense que le modèle fait sa preuve que les échanges entre les gens, même au niveau professionnel, la contribution, la mise en commun des stacks techniques, du code, de travailler ensemble qui était uniquement pratiqué par la communauté du logiciel libre et de l’open source au début est devenu un domaine dominant chez les développeurs.

Je ne sais pas ce que tu en penses pour la sécurité par exemple ?

Pour la sécurité, ça reste encore un peu en marge comme tu disais, parce que malheureusement aujourd’hui, avec la complexité de la détection qu’on embarque aujourd’hui dans la détection d’attaque, très souvent, ça reste le monopole de quelques très grosses entreprises. Même s’il y a des initiatives communautaires, je pense notamment à CrowdSec, qui sont réellement de grosses initiatives communautaires. Pour moi dans le domaine de la sécurité, on est pas encore complètement mature dans le domaine de l’open source, même s’il y a déjà beaucoup d’outils qui existent, je pense notamment à Suricata, Metasploit. On va aussi vers de l’open source, le fait que la sécurité devient le nerf de la guerre va améliorer les choses, et va pousser les gens à aller vers de l’open source aussi.

Tu as abordé un sujet très intéressant, tu as dit que la plupart des clouds providers tournaient aujourd’hui avec Linux. Est-ce que l’open source, ce n’est pas aussi le risque que les mastodontes, notamment les GAFAM, qui récupèrent tous les lauriers ? Je pense notamment au cas qu’on a vu au début de l’année, avec le changement de licence d’ElasticSearch, où c’était la guerre ouverte entre Amazon et Elastic.co sur le fait qu’Amazon avait lancé son offre basée sur ElasticSearch et récoltait un peu tous les lauriers de la solution qui était pourtant une solution open source, maintenue par des dizaines de personnes derrière, mais c’était Amazon qui se faisait de l’argent dessus, et non pas la solution payante que proposait Elastic, qui permettait justement de contribuer à ce projet. Est-ce que justement l’open source, ce n’est pas justement le risque de créer plus de cas comme ça ? On avait déjà eu MongoDB VS Amazon. On avait déjà eu des cas pareils dans le passé, je pense qu’on en aura encore dans le futur. Est-ce que ça ne met pas en péril l’open source aussi ?

Je pense que c’est un problème global. Tu as cité des exemples qu’on peut rattacher au modèle économique et à l’entreprise, Elastic, son principal produit, qui a reçu beaucoup d’aide de la communauté, mais qui est porté par cette société, qui fait un produit efficace, bien fait.

Il avait réussi à trouver un modèle économique, et là en effet, le mastodonte AWS essayait de les ramener à un rôle d’éditeur strict quand eux essayaient justement de développer de l’infrastructure à la demande avec leur propre offre cloud.

AWS les a restreints, contraints et comme ils ont vu qu’Elastic essayait de développer son offre cloud, la guerre était lancée.

Ce qui se fini un peu bizarrement avec un changement de licence pour les produits ElasticSearch, et la création d’un fork plus ou moins maintenu uniquement pas les gens d’AWS, si tu regardes les commiters. Un modèle qui est perdant pour tout le monde je trouve.

J’avais constaté il y a longtemps de ce problème avec AWS qui proposait leur instance Linux [Amazon Linux, basé sur CentOs], qui montrait encore l’envie de mettre en avant leur marque de manière un peu écrasante des autres projets.

Pour répondre à ta question, je n’ai pas du tout la réponse. C’est un problème que je vois criant. Je ne pense pas forcément que ce n’est pas une bonne solution ce qu’a fait Elastic, et que c’est peut-être une surréaction par rapport au danger commercial dans lequel les a mis AWS. Peut-être que c’est la bonne.

Je pense que c’est une plaie ouverte qu’il va falloir suivre de très près. C’est là aussi qu’on voit le point de douleur réel du modèle économique de l’open source qui aujourd’hui est critiquable : les gens travaillent énormément d’heures, et au bout d’un moment quand tu dois choisir entre ton travail de salarié et ton travail pour la communauté, tu finis par faire un travail moyen ou bâclé pour la communauté.

Aujourd’hui, c’est problématique, par exemple sur le domaine de la sécurité, un développeur épuisé qui va commité un mauvais script dans un paquet va par exemple créer une faille d’entropie sur un paquet. C’est ce qui est arrivé sur un paquet SSH il y a quelques années.

Je pense effectivement qu’on a un gros problème à traiter ou au moins à faire évoluer sur le modèle économique de l’open source, et ce n’est pas facile.

Sachant que le changement de licence d’Elastic a aussi provoqué la fuite de beaucoup de développeurs sur la partie open source, parce que beaucoup de développeurs n’ont pas apprécié le changement qui les dépossédait un peu de ce qu’ils avaient fait. C’est le risque que je perçois dans les prochaines années, le cas Elastic n’est pas un cas isolé, c’est le cas de beaucoup de projets open source qui essaient souvent de survivre en poussant une offre payante managée à côté. Et à partir du moment où Amazon, Google, Microsoft, AliBaba se mettent à proposer leurs propres services managés qui reposent dessus, ils utilisent le service, mais n’y contribuent pas forcément. Côté Amazon, on pourrait citer AWS MSK par exemple, basé sur Kafka, ça me surprendrait qu’Amazon soit un énorme contributeur de Kafka, et de l’Apache fundation tout court d’ailleurs.

Un autre sujet que tu as abordé au tout début de cette interview : tu as parlé du télétravail, grâce notamment au projet Debian à faire du télétravail assez tôt. La pandémie actuelle a redistribué pas mal les cartes sur le télétravail, pas mal d’entreprises qui étaient contre, ou disaient que c’était impossible ont réussi à en mettre en quelques semaines. Néanmoins, pour beaucoup d’entreprises, ça reste encore une contrainte et non pas une conviction : elles le font, car elles n’ont pas le choix, et non pas parce qu’elles ont envie de le faire. Est-ce que de ton point de vue, tu penses que c’est quelque chose qui va évoluer dans un sens ou dans l’autre dans les prochaines années ?

En effet, on l’a vu au confinement de 2020 en France est devenu massif, et a été vraiment un choc pour beaucoup de salariés et d’entrepreneurs. Les gens se sont retrouvés confrontés à une culture et un usage qu’ils ne connaissaient pas.

Les entreprises s’y sont mises bon an, mal an, certaines ont bien réussi la transition : elles étaient prêtes, mais restées dans un usage présentiel par habitude tout simplement. Elles ont découvert les avantages du télétravail, elles en faisant déjà quasiment : quand les gens se réunissent dans un bureau et utilisent uniquement des outils pour du télétravail, on déjà à 70/80 % de télétravail on va dire.

Ça a été une catastrophe pour d’autres : les moyens techniques n’étaient pas en place, la culture des salariés, du middle management et du grand management n’étaient pas du tout prêtes, l’entreprise ne pouvait faire qu’un rejet de ce qui allait se passer. Ça a mené à des burnouts de salariés, à des impressions d’inutilité pour les managers, à une impression de fainéantise pour les dirigeants.

La détente, le retour à une préconisation du télétravail légère a été très intéressant. On a vu que certaines entreprises sont revenues dessus immédiatement, le lundi tout le monde devait revenir au bureau.

On a des entreprises qui sont revenues à un jour de télétravail, puis deux, trois. C’est moins que du télétravail à temps complet, mais ça permet d’ancrer le télétravail.

Il y a aussi le cas où les entreprises ont compris les avantages que ça apporte. Je pense notamment aux entreprises éditrices de logiciels, qui réalisaient qu’elles avaient un marché de développeur, qui n’était plus le marché local des développeurs français, mais le marché mondial, ce qui permettait de recruter de manière mondiale.

Il est un peu trop tôt pour le dire, mais je pense que le télétravail, face à cette épreuve "réelle" a réussi à imprégner beaucoup d’entreprises qui ne s’y serait mis que beaucoup plus tard, peut-être dix ans plus tard, je pense qu’en dix mois on fait ce qu’on aurait fait en dix ans.

Est-ce que c’est souhaitable ? Moi, je ne souhaite pas que les gens soient mal : des burnouts il y en a eu. Les métiers comme les nôtres s’y prêtent très bien, je connais des gens qui font du support technique pour lesquels ça ne se passe pas très bien : les gens ne sont plus sur place, donc c’est parfois plus compliqué.

Donc ça a été des contraintes au début, à la détente elles ont pu réfléchir à tout ça.

Je pense qu’on va sur une pente décroissante à la sortie de l’épidémie, parce que le réflexe de revenir en arrière est simple, mais on a aussi montrer que les entreprises n’allaient pas couler avec le télétravail, et ça va laisser quelque chose dans la tête des gens.

Et la recherche des développeurs, qui est aujourd’hui très difficile, pour les entreprises qui produisent du soft vont continuer à promouvoir le télétravail sur cette population qui veut être mobile, nomade numérique.

Tu indiques que les entreprises vont devoir le promouvoir pour pouvoir recruter. Du coup, est-ce qu’on ne reste pas dans quelque chose qui leur ait imposé indirectement, plutôt que dans une vraie conviction, une vraie volonté de mettre en place du télétravail ? Mais plutôt de dire on met du télétravail parce qu’on n’arrivera pas à recruter de toute façon.

Je vais prendre ma casquette d’entrepreneur.

Une entreprise c’est une suite d’habitudes. Ces habitudes, on les appelle des process, en gros c’est des recettes de cuisine qui disent en gros que pour un livreur, le matin il doit chercher les colis à tel endroit à l’entrepôt, passer à tel endroit, rendre le camion le soir, etc.

Ces process se sont formés face aux échecs de l’entreprise souvent.

Une entreprise apprend beaucoup dans la douleur et le fait qu’elle se retrouve face à une contrainte est assez naturel pour une entreprise, les contraintes légales par exemple.

Ça ne veut pas dire qu’à la fin, ça ne devient pas un composant à part entière de l’entreprise. En effet, c’est un peu vécu comme un traumatisme. Beaucoup de managers ont des problèmes avec le télétravail, freinent des quatre fers, car ils se sentent inutiles. Les développeurs poussent au télétravail pour avoir plus de liberté.

Je pense que tout ça va s’équilibrer, et en effet, je pense que ce qui est une contrainte aujourd’hui pour l’entreprise va s’intégrer dans son ADN si elle est obligée de le faire sur une base régulière, tout simplement parce qu’elle va y trouver un avantage au final.

Donc pour toi c’est une contrainte, mais une contrainte qui peut devenir une culture d’entreprise dans les mois/années à venir, comme le RGPD il y a quelques années, qui est maintenant devenu naturelles.

Dernière question, très ouverte. Tu nous as parlé d’open source. Tu nous as parlé d’open source dans le passé. Tu nous as dit ce que tu avais fait pour contribuer à l’open source, ce que tu as mis en place pour promouvoir l’open source. Maintenant si je te dis : dans un court terme, on va dire deux à cinq ans, si je te demandais comment tu vois l’open source dans deux à cinq ans?

C’est-à-dire quels sont les projets que tu vois émerger, les secteurs que tu vois plus ou moins se développer, tu me répondrais quoi ?

Le premier, on l’a abordé tout à l’heure, c’est le modèle économique de l’open source : on est dans un moment de crise où il va se passer quelque chose. Est-ce que ça va être une évolution des licences de base que l’on connaît comme a tenté Elastic, ressenti comme une trahison par les mouvements "durs" de l’open source ?

Est-ce que ça va être quelque chose de plus ouvert, une meilleure considération des entreprises, par forcément normalisé par une licence ? De nouveaux modèles de contribution économique aux projets ?

Je pense qu’on est à une étape charnière, où l’open source va chercher de nouveaux modèles économiques pour à la fois rétribuer les contributeurs qui sont de plus en plus investis sur des modèles de plus en plus complexes sur des projets de plus en plus importants et centraux.

Récemment avec le cas Log4j, qui a mis en exergue le fait que c’était très peu de développeurs qui maintenaient le paquet, qui a eu plusieurs failles majeures d’affilées. Ça a permis de mettre en avant le fait que ce paquet utilisé par des millions de sites, qui était pourtant maintenu par 3 personnes. L’un des premiers points qui a été abordé, c’est justement sur c’était du développement non rétribué et que c’était des gens qui faisaient ça sur leur temps libre.

Github tente un modèle de rémunération par des récompenses. On peut sponsoriser un développeur. C’est quelque chose qui bouge beaucoup aujourd’hui.

L’open source a beaucoup intégré les entreprises dont on doit trouver une solution et ça va se faire de soi-même, je pense, dans les 5 ans à venir.

L’autre point dans le secteur qui va se développer, c’est évidemment le cloud. Moi-même je travaille maintenant dans des missions où on me demande de travailler sur cinq clouds différents et je ne peux pas le faire comme ça. Je passe par des outils tiers, comme Terraform par exemple.

Dans le domaine du cloud et de son infrastructure, c’était plutôt un domaine où on avait tendance à utiliser plutôt des outils propriétaires liés aux matériels. Maintenant qu’on est dans le cloud, ça va être plus variable, et surtout dans le modèle multicloud. La flexibilité de l’open source va lui permettre de jouer un rôle important.

Le dernier projet qui est lié à l’open source, mais pas directement, c’est tout ce qui est réseau pair à pair. On a eu l’exemple du réseau social Mastodon, qui depuis 2017 s’est bien développé.

On a aussi des projets entiers qui communiquent. Par exemple, on peut faire communiquer Mastodon, qui pour rappel est un clone en logiciel libre qui ressemble à Twitter. On peut le faire communiquer avec d’autres outils, par exemple pour un générateur de site web pour faire un agrégateur de lien.

L’optique est d’éviter la centralisation des plateformes et d’éviter la centralisation TikTok, Facebook, Twitter, etc.

On a quelque chose à jouer. Ça évolue lentement parce que les plateformes trustent les utilisateurs et c’est difficile d’en sortir, mais on a quelque chose à faire.

Effectivement, c’est l’approche que j’ai avec Peertube aussi. C’est justement de montrer qu’un web sans les GAFAM existe, et tu penses vraiment que ce modèle, où on va essayer de s’exfiltrer des GAFAM, où va essayer de reprendre notre propriété sur notre contenu va être quelque chose qui va se développer dans les années à venir du coup ?

Oui ! Je pense que ça va aller lentement.

YouTube est devenu extrêmement sensible aux demandes de censures. Twitter suit le même chemin. Facebook est sans cesse attaqué par les législateurs américains parce qu’il serait trop permissif.

On a beaucoup de modèles, ça s’accélère.

Pour beaucoup de population, il n’existe pas d’alternative au logiciel libre, et je pense que de manière continue, pas forcément rapidement, mais continue, ces alternatives vont continuer à se développer.

Merci pour toutes ces réponses, notamment sur l’avenir de l’open source sur les prochaines années. On se recroisera sans doute sur le journal du hacker. J’espère aussi qu’on se recroisera sur d’autres projets open source, car il y a beaucoup à faire, et comme tu l’as dit, l’avenir se construit autour de l’open source.

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 !