The Cloud Optimist

Cloud Souverain : Comment démarrer avec Scaleway

Sun, 17 May 2026 07:30:00 +0100

Pourquoi le Cloud Souverain ?

Ces dernières semaines, le concept de “Cloud Souverain” était partout, comme une évidence. Et pourtant, quand j’ai commencé à m’intéresser au Cloud il y a plusieurs années, personne n’en parlait. C’était déjà une prouesse de comprendre et utiliser le Cloud, alors qu’il soit souverain ou non, franchement, tout le monde s’en fichait.

Mais avec le climat géopolitique actuel, tout le monde s’est souvenu que les trois grands acteurs du Cloud que sont AWS, Azure et GCP sont américains, et que cela pourrait potentiellement poser des problèmes, notamment avec le Cloud Act, qui permet au gouvernement américain d’accéder aux données stockées sur les serveurs de ces entreprises, même s’ils sont situés en dehors des États-Unis.

Ainsi, vous aurez beau dire : “non mais chez nous on utilise la région AWS eu-west-1 en Irlande, donc c’est complètement souverain !”, ça ne changera rien au fait que vos données sont potentiellement accessibles par le gouvernement américain. Et beaucoup d’entreprises ont commencé à en prendre conscience, et à se demander s’il n’était pas temps de chercher une alternative plus souveraine.

Et même si on observe des initiatives de la part des Big Three (je pense notamment à AWS avec son initiative AWS European Sovereign Cloud), on observe une montée en popularité de solutions alternatives, comme Scaleway, qui a su se positionner rapidement comme un acteur majeur du Cloud Souverain en Europe.

Aujourd’hui, j’aimerai donc tester avec vous Scaleway, du point de vue de quelqu’un qui a toujours été habitué à AWS. Serais-je agréablement surpris ? Découvrons-le ensemble !

Premiers pas avec Scaleway

Aperçu de la console

Je vous passerai toute la partie de création de compte. C’est assez simple, et je n’ai pas rencontré de problèmes particuliers.

Maintenant, comme la première impression est importante, voyons voir à quoi ressemble la console d’administration de Scaleway dès notre arrivée.

Ma première bonne surprise, est la notion de projets. Là où chez AWS, pour un même compte, toutes vos ressources co-habitent au même endroit (ce qui peut rendre la recherche de ressources compliquée), chez Scaleway, vous pouvez créer des projets qui viendront grouper vos ressources. Un premier projet “Default” existe déjà, et j’imagine qu’il servira aux ressources “communes” à plusieurs projets.

Au niveau de l’interface utilisateur, sans pour autant révolutionner la navigation (et après tout, ce n’est pas forcément ce qu’on attend), Scaleway utilise une sidebar plutôt épurée, avec un groupement de services en fonction de leur fonction. Qui plus est, chaque service a un nom clair, ce qui permet de rapidement savoir où on veut aller (là où AWS aime bien les noms de services cryptiques).

Allez, fini de rêvasser, et entrons dans le vif du sujet !

Création d’une fonction

Le premier test que j’aimerai faire, c’est de déployer une simple function (aka une AWS Lambda) pour voir les similitudes et différences avec AWS.

Je me rends donc dans Serverless Compute –> Functions. Et je suis déjà perplexe : Scaleway me parle de “namespaces” pour me permettre de grouper mes fonctions. J’ai d’abord pensé à une redite des “projets” vu plus haut, mais les “namespaces” permettent en plus de partager des variables d’environnement entre plusieurs fonctions. Des groupes dans des groupes donc.

Passons là-dessus pour l’instant, et commençons à créer notre première fonction.

Pour commencer, je trouve l’interface très clair, et j’apprécie particulièrement les petites docs glissées à certains endroits, ainsi que la mention “Deprecated” sur les versions des runtimes. Idem pour les coûts estimés dans la colonne de droite, une bonne indication rapide pour voir si on n’est pas en train de faire n’importe quoi ! Au final, cela ressemble beaucoup à du AWS, mais en plus “clean” et plus ordonné.

Il y a tout de même des points qui me chiffonnent un peu :

La request timeout indique un maximum de 900, mais le slider peut monter à 3600
L’input “Average request duration” qui n’a pas l’air de pouvoir être rempli

Une fois que tout est bon, je finis par créer ma fonction. Et là encore, je suis un peu déçu. Il aura fallu plus d’une minute pour déployer cette fonction qui ne contient qu’un simple “Hello World”. J’ai notamment été intrigué par l’étape numéro 3 : “function image is being pushed to container registry”. J’ai trouvé ça assez curieux que Scaleway stocke une image de ma pauvre fonction Hello World. Je suis donc allé voir dans le service “Container Registry” et suprise ! Mon image était bien là, mais avec une taille de 337MB !!! Sachant que le stockage des images sur Scaleway est facturé, je trouve ça un peu fort de café de devoir déjà payé 0.06€ pour un bête Hello World.

Mais revenons à nos fonctions. Un autre point noir concerne l’éditeur de code. Là où chez AWS, on nous offre une expérience proche d’un Visual Studio Code, chez Scaleway, vous n’aurez droit qu’à un simple textarea, avec un seul fichier. Je vous entends déjà dire “de toute façon, modifier du code dans la console, c’est une hérésie !”, et je suis d’accord avec vous. Mais cela montre le retard de Scaleway sur ce point.

En contrepartie, la navigation est quant à elle bien plus agréable et facile pour s’y retrouver. J’apprécie tout particulièrement la partie “Test” qui nous offre une commande curl prête à l’usage (dommage cependant qu’il ne soit pas possible de tester directement depuis la console).

Même exercice avec Terraform

Comme je le disais plus haut, la console c’est bien, mais si on veut se lancer sérieusement dans un provider cloud, alors il faudra passer par la case Infrastructure as Code. Et ici, mon chouchou reste Terraform. Je suis donc curieux de voir comment se passe le déploiement d’une fonction sur Scaleway avec Terraform.

Le jour où j'ai accidentellement supprimé une API, et ce que cela m'a appris sur le DevOps

Tue, 17 Feb 2026 07:30:00 +0100

La journée du 4 avril 2024 avait bien commencé. Un petit café en main, un VS Code en plein ébullition, et de la douce musique électro dans les oreilles, tant de facteurs positifs qui ne pouvaient présager de la catastrophe à venir.

Aujourd’hui, j’aimerai vous raconter comment une journée en apparence tranquille est devenue un moment marquant de ma carrière de DevOps !

Incident

Le contexte

Je travaillais alors dans une équipe avec pour but de mettre à disposition une API Gateway globale sur AWS, avec plusieurs endpoints managés par différentes équipes. Concrètement, la mise en place de cette API Gateway était l’étape initiale du projet. Cela comprenait un record DNS qui pointait vers cette API, l’API Gateway elle-même, ainsi qu’un Cognito Authorizer configuré avec plusieurs clients.

Une fois cette API prête, des équipes externes pouvaient alors déployer leurs propres endpoints sur cette API. Pour cela, une pipeline CI/CD était mise en place, et via CloudFormation, les endpoints se rattachaient directement à l’API déjà créée.

Je simplifie au maximum, si des détails techniques vous intéressent, n’hésitez pas à me contacter !

De mon côté, en plus d’être responsable de l’infrastrcture globale de l’API, il m’arrivait de travailler ou de troubleshooter certains services.

Le début du drame

Si vous avez déjà travaillé avec CloudFormation, vous êtes peut-être familier avec le terme UPDATE_ROLLBACK_FAILED. C’est ce qui arrive lorsque vous essayez de mettre à jour une stack CloudFormation, mais que celle-ci a rencontré un problème. Elle essaiera donc de faire un rollback. Mais si ce rollback n’aboutit pas, votre stack sera alors en UPDATE_ROLLBACK_FAILED.

Et ce UPDATE_ROLLBACK_FAILED est bien embêtant, car vous ne pouvez plus relancer de déploiements tant que vous n’avez pas résolu le problème.

C’est exactement ce qui s’est passé ce fameux 4 avril 2024. Un de nos services s’est retrouvé dans cet état, et j’ai commencé à investiguer le pourquoi du comment.

Après quelques minutes, j’ai constaté que le problème venait de la ressource API elle-même. Sans trop réfléchir, et dans une optique de débloquer le problème rapidement, je me suis rendu directement sur la console AWS, sur le service API Gateway. J’ai cherché la ressource en question, et me suis empressé de la supprimer.

À ce moment précis, quelque chose de très étrange s’est produit. Un comportement inattendu qui m’a glacé le sang. Au lieu de me retrouver sur la même page, AWS m’a renvoyé sur la page principale du service API Gateway. Cette même page qui liste vos APIs disponibles, et qui affichait maintenant le nombre 0.

J’ai ainsi réalisé que je n’avais pas supprimé la ressource API, mais bien l’API Gateway dans sa totalité.

Les détails d’un échec

Jamais je n’aurais pensé commettre une telle bêtise. Et j’imagine que vous lisant ces lignes, vous vous dites la même chose.

Car pour se tromper, il fallait le faire !

Laissez-moi vous faire une reconstitution de la scène du crime. Voici ce que j’ai vu au moment où j’ai pris la décision de supprimer une ressource de l’API Gateway.

Toute ressemblance avec une situation réelle est totalement fortuite

Dans ma situation, sur quel bouton auriez-vous cliqué ? Facile ! Le bouton Delete juste à droite de la ressource !

Pour ma part (et je ne sais toujours pas ce qui m’a poussé à faire cela), j’ai préféré cliquer sur le bouton API actions. Après tout, je voulais en effet faire une action !

Et que se passe-t-il quand on clique sur ce bouton ?

Oula ! De suite, on voit que ce n’est pas du tout ce qu’on veut faire. Mais pensez-vous que cela m’a découragé ? Absolument pas ! J’étais venu pour supprimer une ressource, et quand j’ai vu le mot Delete, je n’ai pas réfléchi plus longtemps ! J’aurais dû, car ainsi, j’aurais sûrement vu le mot API juste à côté.

Heureusement, nos amis de chez AWS ont pensé à tout ! Lorsque vous cliquez sur Delete API, on va tout de même vous demander si vous êtes bel et bien certain de vouloir supprimer cette API. Un beau message s’affiche, vous indiquant le nom de l’API en question, et vous demandant de taper le mot confirm pour valider cette opération.

Tout ça, c’est bien beau, mais les ingénieurs d’AWS ont sous-estimé mon impatience. À ce moment-là, cette demande de confirmation n’était pas une mise en garde, mais un obstacle à mon but de supprimer ma ressource. Ni une ni deux, j’ai entré le mot confirm, et validé l’opération.

Voici donc la dernière chose que j’ai vue avant de finalement réaliser l’erreur que j’avais commise.

Une vision d’horreur

Je voulais absolument vous retracer ce petit parcours pour vous faire comprendre une chose : vous aurez beau mettre en place toutes les sécurités possibles, vous ne pourrez jamais rien faire contre un individu impatient, car ce dernier ne saura pas lire vos avertissements.

Alors, la prochaine fois que vous devrez faire une action somme toute inoffensive, prenez bien le temps de lire et de vous assurer que vous êtes bel et bien sur le bon chemin.

Cela étant dit, passons maintenant à une étape cruciale : la résolution de cet incident !

Résolution

Le déclic

Revenons donc sur le moment du drame. Après avoir réalisé ce qui était arrivé, j’ai eu comme un électrochoc, un éclair de génie (aucune poudre blanche n’ayant pourtant été consommée). Je savais maintenant ce que je devais faire : résoudre l’incident, mais surtout, documenter les actions que j’allais entreprendre.

Car quelques semaines plus tôt, je m’étais intéressé à l’incident GitLab de 2017, celui ayant interrompu le service pendant plusieurs heures, et résultant d’une perte de données pour certains utilisateurs. J’ai ainsi découvert le terme de Post-Morten, et leur intérêt dans ce genre de situation. Mais je garde ça pour la prochaine section de cet article.

En attendant, si vous êtes intéressés par ces sujets-là, je vous conseille la très bonne chaîne Youtube de Kevin Fang qui je le cite : “lit des postmortems et en fait des vidéos de piètre qualité”.

Rollback, impact, et communication

La première chose que je me suis dite, c’est qu’il était peut-être possible de faire une sorte de rollback directement depuis AWS, et d’ainsi réduire au maximum l’impact sur les utilisateurs. Si j’avais correctement lu le message d’avertissement plus haut, j’aurais tout de suite compris que cela était impossible (mais si je l’avais lu, je n’aurais de toute façon pas été dans cette situation).

N’ayant aucun moyen rapide et simple de revenir en arrière, j’étais maintenant confiant que j’étais face à un véritable incident ayant un impact global. J’ai donc dans un premier temps pris soin de comprendre tous les impacts que cette suppression d’API allait avoir. Dans mon cas, non seulement l’API n’était plus disponible (merci Captain Obvious), mais en plus de cela, aucun nouveau déploiement n’était possible jusqu’à ce que l’API soit de nouveau opérationnelle.

Finalement, j’ai fait en sorte d’avertir toute notre équipe interne de la situation. Ainsi, ils étaient au courant de l’incident en cours, et que j’étais en train de travailler à sa résolution.

Analyse et découverte de problèmes

Il était maintenant temps de se retrousser les manches et de trouver un moyen de redéployer cette API Gateway.

En premier lieu, je me suis rendu dans le service CloudFormation, car j’avais souvenir que cette API avait été initialement déployée via ce service. J’ai d’abord essayé de mettre à jour la stack, en pensant que cela pourrait faire revenir ma chère API comme par magie.

Évidemment, cela n’allait pas être aussi simple. La mise à jour de cette stack était maintenant impossible, car la suppression manuelle de l’API avait fait rentrer la stack dans un état “hybride” dont elle n’arrivait pas à se sortir.

La mise à jour de cette stack étant impossible, la suite logique était de la supprimer afin de la déployer à nouveau proprement. Et c’est là que les ennuis ont commencé. Cette fameuse stack CloudFormation produisait plusieurs Outputs. Deux de ces outputs étaient nécessaires à toutes les stacks “enfants” qui avaient jusqu’alors déployé leurs endpoints sur cette API. Ainsi, CloudFormation m’interdisait de supprimer ma stack, car elle pourrait impacter toutes les autres.

Après plusieurs minutes de réflexion pour essayer de trouver d’autres alternatives, cette forte interdépendance m’amena à prendre une décision difficile : supprimer toutes les stacks “enfants” de CloudFormation, pour un total de 81 stacks.

Pour couronner le tout, ces stacks “enfants” n’avaient pas de tags identifiables qui auraient pu nous permettre d’automatiser cette suppression. Heureusement, la plupart d’entre elles avaient un nom avec un préfixe reconnaissable, ce qui m’a permis de faire un bon coup de ménage sur la plupart d’entre elles.

Je vous ai parlé d’interdépendances ? Parce que ce n’est pas fini ! Certaines stacks avaient déployé des buckets S3. Et devinez quoi ? CloudFormation ne voudra pas supprimer votre stack, si votre bucket S3 n’est pas vide ! Et bien sûr, 14 stacks se sont retrouvées dans l’état DELETE_FAILED à cause de cela. Heureusement, le problème se résout assez facilement : après avoir fait un backup de chaque bucket, il suffit de les vider et de relancer la suppression de la stack.

Déploiement de l’API : Le bout du tunnel ?

Étant venu à bout de toutes ces interdépendances, il était maintenant temps de supprimer la stack CloudFormation de l’API Gateway, et de la déployer à nouveau.

La suppression se passa sans plus de problème (Dieu merci), mais évidemment, cela ne fût pas le cas pour sa création.

Déjà, parlons de la stack elle-même. Un fichier YML existait dans un repo GitHub, mais celui-ci n’avait pas été mis à jour depuis des lustres, et je savais que je ferais mieux d’utiliser la définition de la stack présente dans CloudFormation (et oui, je l’ai quand même gardée, pas fou le gars).

Cette stack ne déployait pas uniquement l’API Gateway, mais plusieurs ressources AWS (je ne rentrerai pas dans les détails du pourquoi nous avions besoin de ces ressources dans cet article), dont des Lambdas. Ces dernières se basaient encore sur Python 3.7, version avec laquelle il était impossible de se servir pour créer de nouvelles Lambdas. Heureusement, un petit upgrade en Python 3.12 sera suffisant pour qu’AWS nous laisse tranquille.

Et, à ma grande surprise, la stack se déployait maintenant sans souci !

Mais je vous la fait courte, il restait encore du pain sur la planche ! En effet, il manquait à la stack CloudFormation plusieurs ressources critiques à la bonne exécution de notre API. Des ressources qui avaient été créées à la main dans AWS directement, faisant fi de toute bonne pratique d’Infrastructure as Code (pleure en Terraform). Dans un souci de rétablissement du service le plus rapidement possible (on est DevOps, ou on ne l’est pas !), ces ressources seront donc créées une nouvelle fois à la main.

Pour finir, plusieurs composants clés faisaient référence à l’ARN de l’ancienne API en dur. Il fallait ainsi faire tout un travail d’archéologie pour trouver tous les endroits où une mise à jour vers la nouvelle API s’imposait.

Finalement, après plusieurs heures de troubleshooting, l’API était de nouveau opérationnelle, et les développeurs pouvaient à nouveau déployer leurs projets.

Cet incident aura démarré le 4 avril 2024 à 15h24 et se sera conclu le 5 avril 2024 à 08h46.

Post-Mortem et Lessons Learned

Pendant cet incident, j’ai réalisé une prise de note intensive sur les actions menées. J’avais déjà entendu parler du principe de Post-Mortem, et je pensais que cet incident serait le parfait candidat.

Si vous ignorez le principe d’un Post-Mortem, il agit comme un document retraçant les étapes de résolution d’un incident, couvrant les impacts, et la root cause, mais surtout — et à mon sens le plus intéressant — comporte une section appellée Lessons Learned. Cette section, si vous la prenez au sérieux, sera votre meilleure alliée pour construire une architecture plus robuste et plus durable.

Concrètement, vous allez noter dans cette section trois points clés : ce qui s’est bien passé, ce qui s’est mal passé, et là où vous avez eu de la chance. Et surtout, soyez honnêtes ! Même si certains points vous paraissent bêtes, ou vous font passer pour un incompétent (et je vous dis ça alors que j’ai manuellement supprimé une API, donc prenez-le avec légèreté), le but n’est pas de pointer du doigt (ce qu’on appelle aussi la blameless culture), mais de comprendre les failles dans notre système, afin de les améliorer.

« The cost of failure is education. » — Devin Carraway (Source)

Cela vous paraît peut-être encore un peu flou, alors laissez-moi vous montrer mes lessons learned de cet incident.

What went well

Pendant cet incident, deux choses se sont bien passées.

D’abord, la résolution s’est faite par un membre de l’équipe qui connaissait en profondeur cette architecture, ce qui a permis de comprendre rapidement ce qui devait être remis en place pour restaurer le service.

Enfin, il y a eu une bonne communication tout au long de cet incident. Lorsque le problème s’est présenté, il n’a pas essayé d’être dissimulé, et des mises à jour fréquentes ont été annoncées pour avertir de l’avancement de sa résolution. C’est un point très important, car non seulement vous donnez de la visibilité sur vos actions, mais par la communication, vous pouvez aussi acquérir des informations utiles à la résolution de votre incident (un collègue pourra par exemple vous pointer vers une documentation dont vous n’avez pas connaissance, ou vous donner un coup de main si nécessaire).

What went wrong

Ici, c’est la partie qui fait mal. Comme je vous l’ai dit, il faut ravaler sa fierté, et mettre en lumière tout ce qui aurait pu être mieux exécuté.

Pour cet incident, quatre choses ne se sont pas bien passées.

Pour commencer, l’infrastrucutre de cette API n’était non seulement pas consolidée dans un seul et même fichier (ou dossier), mais était en plus disséminée dans plusieurs repos GitHub. Il était ainsi très compliqué d’avoir une vue d’ensemble de ce qui était nécessaire au bon fonctionnement de cette API.

Ensuite, un gros problème résidait dans ce qu’on appelle le drift. Ce sont toutes les différences que vous avez entre votre infrastructure réelle, et votre infrastructure telle qu’elle est définie dans votre code. Idéalement, aucune modification manuelle ne doit avoit lieu, et tout doit passer par votre fichier d’Infrastructure as Code. Si cela avait était le cas, un simple redéploiement aurait permi une remise en service instantanée.

Un autre problème résidait dans la forte interdépendance de toutes les ressources. Beaucoup par exemple se basaient sur un output de la stack CloudFormation. Si vous enlevez cette stack, vous enlevez ainsi la possibilité de déployer la suite de votre infrastructure.

Enfin, l’identification des ressources liées à notre infrastructure était difficile. Notre stack déployait les ressources sans aucun tag associé, ce qui rendait compliqué la recherche de toutes les ressources nécessaires à notre API.

Where we got lucky

Cette partie peut ressembler à du positif, mais il n’en est rien ! Car vous allez ici parler des élément qui se sont bien passés, mais UNIQUEMENT car vous avez eu de la chance. Comprenez qu’à tout moment, cela aurait pû être un autre point à mettre dans la catégorie “What went wrong”. Donc soyez heureux pour cette fois, mais ne baissez pas votre garde pour autant !

Pour cet incident, trois choses se sont bien passées par chance.

Tout d’abord, l’incident a été immédiatement identifié (c’est au moins l’avantage quand on fait une boulette pareille). Mais cela aurait pû être bien pire ! Car si cette API avait été supprimée par tout autre moyen (un script d’automatisation par exemple), nous n’avions aucun monitoring en place capable de nous prévenir d’une telle chose.

Ensuite, il se trouve que la personne qui a supprimé cette API avait une excellente connaissance du projet et de l’infrastructure (je parle de moi oui, il faut bien s’envoyer quelques fleurs). Cela a permis de très vite enchaîner sur la résolution de l’incident, mais cela aurait pu se passer autrement.

Enfin, cette API était en fait notre API de dev. L’API de prod, elle, allait très bien (détail que j’ai volontairement gardé pour la fin, il paraît que c’est du storytelling). Alors certes, l’impact fût minime, mais l’incident aurait tout de même pû arriver en production, avec les mêmes problématiques de remise en service. Et cela aurait pû coûter bien plus cher.

Préparer le futur

Maintenant que vous avez pu lister les problèmes rencontrés lors de la résolution de cet incident, en tant que bon DevOps, vous vous devez d’en tirer les leçons. Notez bien tout ce qui pourrait être amélioré, mais surtout, fixez-vous un plan ! Sinon, ce ne seront que de vastes phrases sans utilité.

« Tout objectif sans plan n’est qu’un souhait. » — Antoine de Saint-Exupéry

Dans mon cas, les trois leçons clés ont été les suivantes :

Consolidation de l’Infrastructure as Code : tout doit pouvoir être déployé en un clin d’oeil. C’est un chantier que je serai amené à compléter dans les mois qui suivirent (mais cette histoire, c’est pour une prochaine fois).
Amélioration du monitoring et de l’alerting : si cet incident devait de nouveau arriver, il nous faut être averti rapidement afin de réagir en vitesse.
Documentation plus claire et cohérente : n’importe quel membre de l’équipe doit pouvoir faire face à un tel incident, et cela commence par une documentation fiable et compréhensible.

Toutes ces leçons seront ensuite trackées en tant qu’issues GitHub, et je m’appliquerai à les compléter dans les mois qui suivirent (mais cette histoire, c’est pour une prochaine fois).

Conclusion

Vous l’aurez compris, un accident ça arrive. L’essentiel est qu’il soit bénéfique pour vous, et l’ensemble de votre organisation. Servez-vous en comme d’une opportunité d’apprendre et de consolider des failles qui n’était jusqu’alors pas détectées (certaines entreprises s’amusent d’ailleurs même à volontairement créer ce chaos).

Merci de m’avoir lu jusqu’au bout ! Je vous laisse ici, car j’ai d’autres infrastructures à supprimer !

Comment migrer son State de Terraform Cloud vers AWS S3 ?

Wed, 17 Dec 2025 07:30:00 +0200

Introduction

Quand j’ai commencé à utiliser Terraform (notamment pour le déploiement de mon blog), je me suis tourné vers l’utilisation de Terraform Cloud (ce nom a ensuite été modifié en HCP Terraform).

Terraform et le State

Si vous connaissez un peu Terraform, vous êtes sûrement familier avec le terme State, qui correspond en fait à l’état actuel de votre infrastructure, et qui permet à Terraform de savoir quelles modifications seront à prévoir si vous venez à modifier vos fichiers Terraform. Ce State est représenté par un fichier : terraform.tfstate.

Par défaut, Terraform stocke ce fichier en local sur votre machine, mais recommande d’utiliser un backend storage (comprenez : “stockez ce fichier ailleurs bon sang !”).

Évidemment, Terraform vous propose en premier la solution HashiCorp : Terraform Cloud. En créant un compte, vous pourrez gratuitement utiliser leur backend pour stocker vos fichiers de state. C’est tout naturellement ce que j’ai fait il y a quelques années.

La fin de Terraform Cloud

Jusqu’à cette semaine, où j’ai reçu ce mail d’HashiCorp.

Aïe ! Il fallait s’en douter, toutes les bonnes choses ont une fin ! L’option gratuite de l’époque n’existera bientôt plus, et il me faut donc faire un choix : mettre à jour mon “plan” HashiCorp, ou aller stocker mes states ailleurs.

En regardant de plus près leurs offres actuelles, HashiCorp propose encore une version gratuite, bien que limitée dans le nombre de ressources pouvant être déployées (500 aujourd’hui). C’est une offre assez généreuse, mais ne sachant pas comment celle-ci pourra évoluer, je prends la décision de déménager mes States une bonne fois pour toutes.

Adieu, Terraform Cloud !

Une alternative pour stocker vos states

Heureusement pour moi, il existe bien des moyens pour stocker son state Terraform, et ce grâce au Remote State.

Pour faire simple, il suffit de dire à Terraform où sera stocké votre fichier de state. On utilise pour cela le block backend.

Il en existe une bonne poignée, mais possédant un compte AWS sur lequel je déploie toutes mes ressources, je me dirige tout naturellement vers le backend S3.

Voici par exemple comment configurer un backend S3 avec Terraform.

terraform {
  backend "s3" {
    bucket = "mybucket"
    key    = "path/to/my/key/terraform.tfstate"
    region = "eu-west-1"
  }
}

Maintenant qu’une alternative a été trouvée, il est temps de passer à la migration !

Migration du state vers S3

Je vais prendre en exemple la migration du state dont je me sers pour déployer ce blog.

Actuellement, si on regarde mon workflow GitHub Actions de déploiement, on voit que je m’authentifie avec un token à mon compte Terraform Cloud. Cette partie-là n’aura plus de raison d’exister (du moins pour les credentials, il faudra toujours initialiser la CLI Terraform).

Ensuite, il va falloir créer un bucket S3 qui contiendra les futurs fichiers de state.

Enfin, il faudra rajouter un block backend à mon projet afin d’indiquer à Terraform de ne plus utiliser Terraform Cloud, mais bien S3 lorsqu’il viendra utiliser le state.

Attention, nous n’avons pas encore fini ! Car si je laisse ce bucket vide, la prochaine fois que j’essaierai de déployer mon blog, Terraform viendra se baser sur un state… inexistant ! Et pensera donc qu’aucune ressource n’a encore été déployée sur mon compte AWS. Terraform essaiera ainsi de recréer des ressources déjà existantes.

La dernière étape sera donc de récupérer le fichier de state de mon projet de blog, et de le déplacer dans mon bucket S3.

Je dois ensuite m’assurer que les informations que j’ai fournies dans le block backend correspondent bien à la réalité.

Une fois tout cela prêt, il est temps de tester et de déployer tout ça !

J’ai volontairement omis quelques étapes de cette migration (des variables de workspace à migrer, l’utilisation de GitHub Secrets pour le nom du bucket S3, l’ajout des credentials AWS dans la GitHub Actions, …) pour rendre cet article plus concis. Si vous voulez en voir plus, rendez-vous dans la Pull Request que j’ai ouverte pour réaliser cette migration.

Si tout s’est passé comme prévu, vous devriez voir apparaitre la phrase No changes. Your infrastructure matches the configuration. lors de votre terraform plan !

Conclusion

Il est toujours pénible de devoir réaliser des migrations sur des infrastructures qui sont déjà en place. Mais avec un peu de temps, et avec une bonne volonté, c’est le genre de tâche qui ne prend au final que quelques heures.

Alors, n’attendez pas le dernier moment, et lancez-vous !

Comment et pourquoi configurer AWS IAM Identity Center sur votre compte AWS

Wed, 19 Nov 2025 07:30:00 +0200

Introduction

Si vous jonglez avec plusieurs comptes AWS, ou même un seul compte avec différents utilisateurs, vous savez à quel point la gestion des accès peut devenir un véritable casse-tête. Créer des utilisateurs IAM individuels dans chaque compte, gérer leurs permissions, s’assurer que tout le monde utilise le MFA… Ouf, rien que d’y penser, ça peut donner des sueurs froides ! Et si je vous disais qu’il existe une solution élégante, centralisée et bien plus sécurisée pour gérer tout ça ? Mesdames et Messieurs, laissez-moi vous présenter IAM Identity Center !

Depuis que j’ai découvert et mis en place IAM Identity Center (que certains connaissent peut-être sous son ancien nom, AWS Single Sign-On ou AWS SSO), ma vie d’administrateur Cloud a radicalement changé. C’est le genre d’outil qui, une fois adopté, vous fait vous demander comment vous avez pu vivre sans.

Alors, qu’est-ce que c’est exactement, et pourquoi est-ce si génial ? C’est ce qu’on va voir ensemble.

IAM Identity Center : Késako ?

En termes simples, IAM Identity Center est un service AWS qui vous permet de gérer de manière centralisée l’accès à tous vos comptes AWS et à vos applications Cloud. Que vous ayez une poignée de comptes ou une organisation AWS tentaculaire avec des dizaines, voire des centaines de comptes, IAM Identity Center est là pour vous simplifier la tâche.

Il vous offre un point d’entrée unique (un portail d’accès web) pour vos utilisateurs, leur permettant d’accéder aux rôles et aux comptes auxquels ils ont droit, le tout avec une seule authentification.

Les avantages d’IAM Identity Center

Si je suis aussi enthousiaste, c’est parce que les bénéfices sont nombreux et significatifs. Pour vous citer les plus importants :

Single Sign-On (SSO) : Vos utilisateurs se connectent une seule fois via le portail AWS (ou via votre fournisseur d’identité existant si vous en avez un) et accèdent ensuite à tous les comptes et rôles qui leur sont assignés, sans avoir à se ré-authentifier pour chaque compte.
Gestion Centralisée : Vous gérez tous vos utilisateurs, groupes et leurs permissions (via des Permission Sets) depuis un seul endroit, même s’ils doivent accéder à des dizaines de comptes AWS différents.
Identifiants Temporaires : C’est l’un des points les plus importants ! Lorsque les utilisateurs accèdent à un compte via IAM Identity Center, ils obtiennent des identifiants temporaires à durée de vie limitée. Adieu les Access Keys IAM qui traînent et qui représentent un risque de sécurité majeur.
MFA (Multi-Factor Authentication) : Vous pouvez (et devriez !) imposer l’utilisation du MFA directement au niveau de la connexion à IAM Identity Center.

Si j’ai piqué votre curiosité et que vous souhaitez en savoir plus, je vous laisse consulter la documentation AWS sur IAM Identity Center. Pour ceux qui sont déjà convaincus, continuons ensemble !

Se Lancer avec IAM Identity Center

Mettre en place IAM Identity Center est étonnamment simple, surtout si vous utilisez l’annuaire intégré d’Identity Center comme source d’identité. Voici les étapes clés pour démarrer :

Configuration initiale : Rendez-vous dans la console AWS, et cherchez IAM Identity Center. Attention, choisissez bien votre région AWS pour héberger IAM Identity Center dès le départ, car il est actuellement complexe de changer la région d’IAM Identity Center une fois configuré. La configuration initiale est souvent guidée et rapide. Vous choisirez votre source d’identité (l’annuaire Identity Center, AWS Managed Microsoft AD, ou un fournisseur externe).
Création de groupes et d’utilisateurs : Définissez des groupes pertinents pour votre organisation (ex: Developers, Administrators, …). Créez ensuite vos utilisateurs et assignez-les à ces groupes. Si vous utilisez un IdP externe, cette étape consistera plutôt à synchroniser vos utilisateurs et groupes existants.
Création des Permission Sets : Un Permission Set est un ensemble de permissions (similaire à une policy IAM) que vous allez pouvoir réutiliser. Vous pouvez partir de policies managées par AWS (ex: AdministratorAccess ou ReadOnlyAccess) ou créer les vôtres.
Assignation des accès : C’est ici que la magie opère. Vous assignez un groupe (ou un utilisateur) à un ou plusieurs comptes AWS, en leur donnant le droit d’utiliser un Permission Set spécifique sur ces comptes. Par exemple, le groupe Developers peut avoir le Permission Set PowerUserAccess sur les comptes AWS de développement.
Imposer le MFA : Dans les paramètres d’IAM Identity Center, configurez le MFA pour qu’il soit obligatoire pour tous vos utilisateurs.
Partager l’URL d’accès AWS : Chaque configuration IAM Identity Center a une URL unique pour le portail d’accès (ex: d-xxxxxxxxxx.awsapps.com/start). C’est cette URL que vos utilisateurs mettront en favori pour se connecter.

Une fois connectés au portail, les utilisateurs verront la liste des comptes AWS et des rôles (définis par les Permission Sets) auxquels ils ont accès. Un clic, et ils sont dans la console du compte AWS choisi avec les bonnes permissions !

Ils peuvent aussi obtenir des identifiants temporaires pour la CLI. Mais d’ailleurs, comment faire pour se connecter à un compte AWS en CLI via IAM Identity Center ? Voyons ça ensemble !

Configurer les accès CLI

La documentation d’AWS pour configurer l’authentification CLI avec IAM Identity Center est assez claire, mais je vais tout de même vous décrire les étapes. Je pars du principe que vous avez déjà installé votre AWS CLI.

La commande pour initier la configuration est la suivante :

`1`	`aws configure sso`

Ensuite, vous allez devoir rentrer quelques informations propres à votre IAM Identity Center. Le plus important étant le SSO start URL (que vous pouvez trouver dans IAM Identity Center sous le nom de AWS access portal URL, URL qui finit par /start). Il faut ensuite rentrer la région dans laquelle se trouve votre configuration, quant au SSO registration scopes, vous pouvez laisser la valeur par défaut.

SSO session name (Recommended): default
SSO start URL [None]: https://xxxxxxxxxxxx.awsapps.com/start
SSO region [None]: eu-west-1
SSO registration scopes [sso:account:access]:

Si tout se passe bien, une fenêtre devrait s’ouvrir dans votre navigateur pour valider votre identité. Une fois cela fait, retournez dans votre terminal.

Dans mon cas, je ne possède qu’un seul compte AWS, et IAM Identity Center me le sélectionne par défaut. Mais vous aurez peut-être le choix dans le compte AWS à sélectionner. Idem pour le role.

Enfin, choisissez un nom de profil à utiliser pour vos futurs appels API. Je vous conseille d’utiliser default, ce qui vous permettra de ne pas avoir à rajouter --profile my-aws-profile à la fin de chacune de vos commandes.

The only AWS account available to you is: xxxxxxxxxxxx
Using the account ID xxxxxxxxxxxx
The only role available to you is: AdministratorAccess
Using the role name "AdministratorAccess"
Default client Region [None]: eu-west-1
CLI default output format (json if not specified) [None]: json
Profile name [AdministratorAccess-xxxxxxxxxxxx]: default
The AWS CLI is now configured to use the default profile.
Run the following command to verify your configuration:

aws sts get-caller-identity

Et voilà, le tour est joué !

Conclusion

Vous l’aurez compris, je suis un grand fan d’AWS IAM Identity Center. Il apporte une couche de sécurité indispensable tout en simplifiant considérablement la gestion des accès, que ce soit pour les administrateurs ou pour les utilisateurs.

C’est un véritable pilier pour une infrastructure AWS bien gérée et sécurisée. Si vous ne l’utilisez pas encore, je vous encourage vivement à explorer sa mise en place. C’est un investissement en temps minime pour des gains en sécurité et en efficacité énormes.

Votre infrastructure (et vos équipes de sécurité) vous diront merci !

Sur la piste de la ressource perdue - Mon enquête avec Athena et CloudTrail

Wed, 09 Jul 2025 12:30:00 +0200

Introduction

Récemment, j’ai dû jouer les détectives sur notre compte AWS.

Une ressource était là (un Cognito User Pool), bien présente, mais personne ne se souvenait de son origine. Et évidemment, pas de tags pour nous aider (si seulement ils avaient lu mon article sur le tagging des ressources AWS).

Ma mission, si je l’acceptais : découvrir qui l’avait créée. Le problème ? L’événement datait d’il y a environ quatre mois.

Mon premier réflexe a été de me tourner vers AWS CloudTrail. Et là, premier mur : l’historique des événements n’est consultable que sur les 90 derniers jours. Raté !

Heureusement, je savais que nos logs CloudTrail étaient archivés dans un bucket S3. Mon premier réflexe : télécharger manuellement les archives du bon mois, décompresser des dizaines de fichiers JSON, et lancer un Ctrl+F en priant très fort. Autant vous dire que ce n’est ni efficace, ni agréable, ni rapide.

Je me suis donc demandé s’il n’y avait pas un moyen plus simple de chercher dans cet amas de logs, et j’ai finalement trouvé la solution parfaite : AWS Athena.

Interroger vos logs S3 avec Athena

Pour ceux qui ne connaissent pas, AWS Athena est un service de requête interactif qui facilite l’analyse de données directement dans Amazon S3 en utilisant du SQL standard. En gros, vous pouvez faire des requêtes sur des fichiers (JSON, CSV, …) comme s’il s’agissait d’une base de données traditionnelle. Plus besoin de télécharger quoi que ce soit !

L’idée est donc de “mapper” nos logs CloudTrail stockés dans S3 à une table dans Athena. Pour cela, on utilise une seule requête CREATE EXTERNAL TABLE. En suivant la documentation d’AWS sur le sujet, j’ai lancé la requête suivante dans la console Athena.

Cette requête crée une table et utilise une fonctionnalité très pratique appelée “partition projection”. Cela permet à Athena de déduire l’emplacement des logs en fonction de la date, sans avoir à gérer manuellement les partitions. C’est d’autant plus pratique quand la structure est bien standardisée comme c’est le cas avec AWS CloudTrail.

CREATE EXTERNAL TABLE cloudtrail_logs_pp (
    eventversion STRING,
    useridentity STRUCT<
        arn:STRING
    >,
    eventtime STRING,
    eventsource STRING,
    eventname STRING,
    awsregion STRING,
    requestparameters STRING,
    responseelements STRING,
    additionaleventdata STRING,
    requestid STRING,
    eventid STRING,
    resources ARRAY<STRUCT<
        arn:STRING,
        accountid:STRING,
        type:STRING
    >>,
    eventtype STRING,
    eventcategory STRING
)
PARTITIONED BY (
    `timestamp` string
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://BUCKET-NAME/AWSLogs/ACCOUNT-ID/CloudTrail/REGION' -- Remplacez par le chemin de votre bucket S3
TBLPROPERTIES (
    'projection.enabled'='true',
    'projection.timestamp.format'='yyyy/MM/dd',
    'projection.timestamp.interval'='1',
    'projection.timestamp.interval.unit'='DAYS',
    'projection.timestamp.range'='2024/01/01,NOW', -- Remplacez par la date de début
    'projection.timestamp.type'='date',
    'storage.location.template'='s3://BUCKET-NAME/AWSLogs/ACCOUNT-ID/CloudTrail/REGION/${timestamp}' -- Remplacez par le chemin de votre bucket S3
)

Attention : N’oubliez pas de remplacer les URLs s3://... par le chemin exact de votre bucket S3 où sont stockés vos logs CloudTrail, et d’ajuster la propriété projection.timestamp.range à la période qui vous intéresse.

L’Heure de l’Enquête : Trouver l’Information

Une fois la table créée (ce qui ne prend que quelques secondes), le plus dur est fait ! Mon enquête pouvait enfin commencer.

Je cherchais à savoir qui avait créé un UserPoolClient pour Cognito à une date précise. Ma requête SQL ressemblait donc à ça :

SELECT
    eventTime,
    eventName,
    userIdentity.arn
FROM
    cloudtrail_logs_pp
WHERE
    timestamp = '2025/02/25'
    AND eventName = 'CreateUserPoolClient';

En quelques secondes, Athena a scanné les logs du jour demandé et m’a retourné le résultat.

J’avais l’heure exacte, l’événement, et surtout, l’ARN de l’utilisateur qui avait effectué l’action. Mission accomplie !

Le Verdict… et le Coupable

Le plus drôle dans cette histoire ?

Après avoir mis en place cette solution et retrouvé l’information si facilement, j’ai découvert que le “coupable” qui avait créé cette ressource il y a quatre mois… c’était moi. J’avais complètement oublié !

Au-delà de l’anecdote, cette expérience m’a confirmé une chose : prendre quelques minutes pour configurer Athena sur vos logs CloudTrail est un investissement incroyablement rentable. Vous vous offrez une capacité d’audit et de recherche sur le long terme qui vous sauvera des heures de recherche manuelle le jour où vous en aurez vraiment besoin. Ne faites pas comme moi, n’attendez pas d’être coincé pour le mettre en place !

Pourquoi taguer vos ressources AWS est indispensable ?

Tue, 24 Jun 2025 07:30:00 +0200

Introduction

Plus on déploie de services sur AWS, plus on commence à s’y perdre. Au début, on connaît par coeur tous les services qu’on utilise, le nombre de Lambdas ou d’EC2 qui sont lancées. Mais petit à petit, il est facile de ne plus savoir où donner de la tête, surtout lorsque différents projets s’accumulent. Retrouver rapidement quelles ressources appartiennent à quel projet, ou identifier celles qui n’ont pas été correctement nettoyées après un PoC, tout cela peut vite devenir un casse-tête. Et c’est sans parler de la vision des coûts !

Heureusement, il existe une pratique simple mais incroyablement puissante : le tagging.

Dans cet article, j’aimerais vous montrer qu’une bonne stratégie de tags est cruciale pour votre organisation, votre gestion des coûts, et pour la sécurité de votre compte AWS.

À vos marques. Prêts ? Taguez !

Pourquoi les tags sont-ils utiles ?

Imaginez des étiquettes sur des boîtes de déménagement. Sans elles, impossible de savoir ce qu’il y a dedans ou à quelle pièce elles appartiennent. Les tags sur AWS, c’est pareil ! Un tag est une information (sous la forme clé-valeur) que vous assignez à vos ressources (instances EC2, buckets S3, bases de données RDS, etc.).

Une bonne stratégie de tagging vous permet notamment de :

Identifier des ressources orphelines : C’est le grand classique. Une ressource sans tag Project ou Owner ? Il y a de fortes chances qu’elle ait été oubliée et qu’elle consomme des ressources (et donc de l’argent) pour rien. Lister les ressources non taguées (ou mal taguées) est une première étape essentielle pour faire le ménage.
Ventiler les coûts : En taguant vos ressources avec un identifiant de projet, de centre de coût, ou d’équipe, vous pouvez ensuite utiliser AWS Cost Explorer pour filtrer vos dépenses et comprendre précisément quels projets consomment le plus. Indispensable pour la refacturation interne ou simplement pour optimiser votre budget.
Automatiser des actions : Les tags peuvent servir de déclencheurs pour des scripts d’automatisation (par exemple, sauvegarder toutes les instances EC2 avec le tag Backup=Daily).
Gérer les accès et la sécurité : Le service AWS IAM peut utiliser les tags pour accorder des permissions granulaires.

Bref, taguer, c’est la base d’une bonne gouvernance Cloud. Pour plus de détails, je vous invite à consulter le guide de tagging proposé par AWS.

On peut fort heureusement associer plusieurs tags à une même ressource. Mais cela pose la question : combien de tags sont nécessaires ?

Cela va dépendre de votre entreprise et de chaque projet, mais globalement, il y a des tags qui ne font pas de mal, peu importe votre situation :

Project : Le nom du projet lié à la ressource. Généralement, le nom du repository GitHub fait l’affaire
Environment : L’environnement désiré (dev, val, prod, …). Même si vous avez des comptes AWS cloisonnés, cela vous permettra d’identifier si une ressource s’est perdue durant un déploiement
Owner : L’owner de la ressource. Cela pourrait être une personne, mais plus idéalement une équipe (frontend, backend, security, …)

Selon votre usage, vous aurez sûrement d’autres idées de tags, mais avec ceux-ci, ce sera déjà un bon début ! Et dans le doute, n’hésitez pas à consulter les best practices de tagging recommandées par AWS.

Voyons maintenant quelques cas concrets de l’utilité des tags dans AWS.

AWS Cost Explorer : Suivre les coûts grâce aux tags

L’un des avantages les plus concrets du tagging est la visibilité qu’il apporte sur vos dépenses. AWS Cost Explorer est l’outil de prédilection pour cela.

Une fois vos ressources correctement taguées (par exemple, avec le tag Project), vous devez activer ces tags pour l’allocation des coûts dans la console de gestion de la facturation AWS (Billing and Cost Management -> Cost Organization -> Cost Allocation Tags). Attention, il peut y avoir un délai avant que les tags activés n’apparaissent dans Cost Explorer.

Une fois activés, vous pouvez :

Filtrer par tag : Dans Cost Explorer, vous pouvez filtrer vos coûts par la valeur d’un tag spécifique.
Grouper par tag : Vous pouvez également choisir de grouper vos dépenses par tag. Cela vous donnera une vue d’ensemble de la répartition des coûts entre les différents projets, environnements, etc.
Créer des budgets basés sur les tags : Avec AWS Budgets, vous pouvez définir des seuils d’alerte pour les coûts associés à des tags spécifiques, vous aidant à éviter les mauvaises surprises.

Exemple de filtrage par tag pour mon blog : les coûts sont minimes, suis-je un expert FinOps ?

Cette capacité à disséquer votre facture AWS par tags transforme la gestion des coûts d’une corvée obscure en un exercice transparent et contrôlable. C’est un must pour toute organisation soucieuse de son budget Cloud. Vous pourrez désormais rajouter FinOps dans votre bio LinkedIn !

AWS Resource Explorer : Garder un œil sur les ressources déployées

Maintenant que l’on est convaincu de l’utilité des tags, comment fait-on pour lister toutes les ressources qui utilisent un tag précis ? Nous allons le voir ensemble avec une partie dans la console AWS, et une partie qui se passera dans le terminal (pour tous les geeks qui lisent cet article !).

L’exploration visuelle dans la console AWS

Si vous n’êtes pas encore familier avec AWS Resource Explorer, c’est le moment de le découvrir ! Ce service, relativement récent, vous permet de rechercher et de découvrir vos ressources AWS à travers toutes les régions de votre compte, en utilisant une interface simple, un peu comme un moteur de recherche.

L’avantage principal de Resource Explorer est sa capacité à vous donner une vue unifiée. Plus besoin de sauter de région en région. Vous activez l’indexation, et ensuite, vous pouvez rechercher vos ressources par nom, ID, et bien sûr… par tag !

C’est un excellent outil pour :

Avoir une vue d’ensemble rapide.
Explorer visuellement les ressources associées à un tag spécifique.
Identifier rapidement des ressources sans avoir à coder quoi que ce soit.

Pour l’utiliser, activez-le dans les régions souhaitées (ou toutes), laissez-le indexer vos ressources, puis utilisez la barre de recherche avec une syntaxe comme tag.key:Project tag.value:Cloud*.

Exemple de recherche par tag pour mon blog : seulement trois ressources permettent de gérer ce blog !

Une approche plus technique avec AWS CLI

Pour ceux qui, comme moi, aiment avoir la main via la ligne de commande, ou qui ont besoin d’automatiser ces recherches, l’AWS CLI reste une alliée de choix. Plus précisément, c’est le service resourcegroupstaggingapi qui va nous intéresser.

La commande clé est get-resources. Voici un exemple typique pour lister les ARN de toutes les ressources ayant le tag Project avec la valeur “Cloud Antoine Delia” :

1
2
3

aws resourcegroupstaggingapi get-resources \
    --tag-filters "Key=Project,Values=Cloud Antoine Delia" \
    | jq "[.ResourceTagMappingList[].ResourceARN]"

Ce qui nous donne :

1
2
3

[
  "arn:aws:s3:::antoiXXXXXXXXXXXXX"
]

Décortiquons un peu :

aws resourcegroupstaggingapi get-resources : C’est l’appel à l’API, jusqu’ici, tout va bien.
--tag-filters "Key=Project,Values=Cloud Antoine Delia" : C’est ici qu’on spécifie notre filtre. On cherche le tag Project qui a la valeur “Cloud Antoine Delia”. Vous pouvez ajouter plusieurs filtres.
| jq "[.ResourceTagMappingList[].ResourceARN]" : jq est un outil formidable pour manipuler du JSON en ligne de commande. Ici, on l’utilise pour extraire proprement la liste des ARN des ressources trouvées (vous pouvez vous en passer, mais pourquoi se compliquer la vie ?).

Eh attends une minute ! Dans la console, tu nous montres trois ressources, et là il n’y en a plus qu’une ! Elle est où l’arnaque ?

Habilement remarqué ! Il faut savoir que lorsque vous faites votre appel à l’API, vous utilisez une region par défaut. Or, si vous avez des ressources dans diverses régions, il faudra le spécifier. Ainsi, si l’on ajoute --region us-east-1 juste avant le pipe jq, on obtient bien nos deux ressources manquantes.

[
  "arn:aws:acm:us-east-1:6XXXXXXXXXXX0:certificate/f4ca3b13-XXXXXXXXXXXXX",
  "arn:aws:cloudfront::6XXXXXXXXXXX0:distribution/ERSXXXXXXXXXX"
]

Outre ce détail qu’il ne vous faudra pas oublier, cette commande est extrêmement puissante car vous pouvez l’intégrer dans des scripts pour :

Générer des rapports réguliers sur les ressources par projet.
Détecter automatiquement les ressources qui ne respectent pas votre politique de tagging.
Combiner avec d’autres commandes AWS CLI pour effectuer des actions sur les ressources listées.

Par exemple, vous pourriez ainsi lister toutes vos ressources d’un certain type (ex: toutes vos instances EC2) et de vérifier celles à qui il manque des tags essentiels.

Et si vous vous demandez si AWS n’offre pas déjà un service pour ça… C’est le cas ! Mais nous en parlerons dans un futur article (pour les curieux, je veux parler d’AWS Config).

AWS IAM : Sécuriser l’utilisation de vos ressources

Vos ressources sont déployées dans AWS, et vous souhaitez maintenant donner à une équipe la permission de gérer tout cela.

Seulement voilà, dans votre compte AWS, vous avez aussi des ressources critiques qui ne doivent surtout pas être compromises.

AWS IAM est là pour vous ! À l’aide d’une simple policy, vous pouvez spécifier que seules les ressources comportant un certain tag peuvent être modifiées par un utilisateur ou un groupe.

Prenons par exemple le cas suivant : vous aimeriez la possibilité à une équipe de démarrer ou stopper certaines instances EC2, mais de les empêcher d’accidentellement stopper une instance EC2 critique !

Il vous suffit d’ajouter la policy suivante à vos utilisateurs :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowStartStopEC2IfProjectCloud",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "Cloud Antoine Delia"
        }
      }
    },
    {
      "Sid": "AllowDescribeToSeeInstances",
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    }
  ]
}

Ainsi, vos utilisateurs seront autonomes dans l’utilisation de leurs ressources, sans pour autant avoir la possibilité d’impacter d’autres ressources.

Conclusion

Vous l’aurez compris, une stratégie de tagging rigoureuse n’est pas une option, c’est une nécessité pour opérer sereinement sur AWS. Que ce soit sur le plan organisationnel, financier, ou encore dans la gestion de la sécurité, AWS vous donne les moyens de tirer pleinement parti de vos tags.

Alors, un petit conseil : si ce n’est pas déjà fait, définissez une politique de tagging claire dans votre organisation, appliquez-la, et utilisez ces outils pour vérifier régulièrement que tout est en ordre. Vous m’en remercierez plus tard !

uv : La meilleure chose qui soit arrivée à Python - et pourquoi vous devriez l'utiliser

Mon, 26 May 2025 07:30:00 +0200

Introduction

Python est sûrement mon langage de programmation préféré. Sa simplicité permet en un rien de temps de développer des scripts, des backends, voire même des sites internet, sans pour autant se faire des nœuds au cerveau.

Mais il y a toujours eu une chose qui me déplaisait chez Python : ses outils de packaging. Pendant longtemps, je me suis tenu à l’écart de tous ces outils comme Poetry, car bien franchement, je n’y comprenais rien !

Et puis, j’ai fait une découverte qui, non seulement m’a montré que packager son code Python est une tâche toute simple, mais qui en plus a complètement changé toutes mes habitudes.

Je veux parler de uv.

Créé par la même équipe talentueuse de chez Astral (qui nous avait déjà régalé avec leur outil ruff), uv est présenté comme un installateur et résolveur de paquets Python “extrêmement rapide”. Cet outil est ce qu’on pourrait appeler un game-changer : une fois que vous y avez goûté, impossible de revenir en arrière !

Alors, qu’est-ce que uv a de si spécial ? Pourquoi cet engouement ? C’est ce que nous allons décortiquer ensemble. Accrochez-vous, vous pourriez bien avoir un nouveau coup de foudre !

Ce guide se base sur mon expérience avec uv et les exemples ont été testés avec la version 0.7.3. Selon votre configuration, notamment derrière certains proxys d’entreprise, vous pourriez avoir besoin d’ajouter l’option --native-tls à certaines commandes uv si vous rencontrez des soucis de connexion SSL.)

uv, c’est quoi au juste ?

En quelques mots, uv est un outil en ligne de commande qui ambitionne de remplacer pip, pip-tools, venv, pyenv, et même une partie de virtualenv et pipx, tout en étant beaucoup, beaucoup plus rapide. Oui, rien que ça !

Comme nombre de nouveaux outils à la mode, il est écrit en Rust. Pardon, je devrais dire, il est écrit en ✨ Rust ✨. Ce qui explique en grande partie ses performances fulgurantes.

Préambule

Avant de nous lancer tête la première dans uv et son fonctionnement, j’aimerais en premier lieu vous indiquer la façon dont uv gère les dépendances, les environnements virtuels, et l’installation des versions de Python. Cela m’a plutôt dérouté la première fois que j’y ai été confronté, et je pense donc qu’il est important de le mentionner avant toute chose.

Gestion des dépendances

uv base toute sa configuration sur votre fichier pyproject.toml. Si vous aviez l’habitude d’utiliser un requirements.txt par exemple, sachez que uv l’ignorera complètement.

Comme je suis sympa, je vous mets ici un gist d’un template de pyproject.toml que j’utilise à chaque fois pour démarrer un nouveau projet Python.

pyproject.toml

[project]
name = "project-name"
version = "0.1.0"
description = "Project description"
readme = "README.md"
requires-python = ">=3.12"

[[tool.uv.index]]
name = "votre-index"
url = "https://mon-artifactory.corp/api/pypi/mon-repo-virtual"
publish-url = "https://mon-artifactory.corp/api/pypi/mon-repo-local"
default = true

[tool.ruff]
# Exclude common directories that are typically not part of the source code or are generated by tools.
exclude = [
    ".bzr",
    ".cache",
    ".direnv",
    ".eggs",
    ".git",
    ".git-rewrite",
    ".hg",
    ".mypy_cache",
    ".nox",
    ".pants.d",
    ".pytype",
    ".ruff_cache",
    ".svn",
    ".tox",
    ".venv",
    "__pypackages__",
    "_build",
    "buck-out",
    "build",
    "dist",
    "node_modules",
    "venv",
]
 
# Set the maximum line length to 127 characters.
line-length = 127
 
# Define the number of spaces used for indentation, aligning with Black's style.
indent-width = 4
 
# The minimum Python version to target, e.g., when considering automatic code upgrades,
# like rewriting type annotations
target-version = "py312"
 
[tool.ruff.lint]
# Enable Pyflakes (F) and a subset of the pycodestyle (E) codes by default.
# pycodestyle warnings (W)
# Activate Security Rules (S) to replace bandit
# Enable the isort rules (I) to replace isort
# flake8-bugbear (B)
# flake8-simplify (SIM)
select = ["F", "E4", "E7", "E9", "W", "S", "I", "B", "SIM", "PGH004"]
ignore = [] # List any rules to be ignored, currently empty.
 
# Allow auto-fixing of all enabled rules when using the `--fix` option.
fixable = ["ALL"]
unfixable = [] # Specify rules that cannot be auto-fixed, if any.
 
# Define a regex pattern for allowed unused variables (typically underscore-prefixed).
dummy-variable-rgx = "^(_+|(_+[a-zA-Z0-9_]*[a-zA-Z0-9]+?))$"
 
[tool.ruff.format]
# Enforce double quotes for strings, following Black's style.
quote-style = "double"
 
# Use spaces for indentation, in line with Black's formatting style.
indent-style = "space"
 
# Keep magic trailing commas, a feature of Black's formatting.
skip-magic-trailing-comma = false
 
# Automatically detect and use the appropriate line ending style.
line-ending = "auto"
 
# Update this with your package name or directory to be scanned by pytest-cov
[tool.pytest.ini_options]
addopts = "-s --no-header --cov=src --cov-fail-under=50" # force cmd flags
testpaths = [ # what directories contain tests
    "tests",
]
pythonpath = [ # what to add to the python path
    "."
]

Au lieu d’ajouter vos dépendances à la main, vous pouvez maintenant utiliser uv add <package_name>, et celui-ci sera ajouté à votre pyproject.toml.

Attention cependant, car certains outils externes se basent toujours sur un fichier requirements.txt. Vous aurez donc peut-être besoin de lancer la commande uv pip compile -o requirements.txt dans votre pipeline CI/CD.

Environnement virtuel

Comme moi, vous aviez peut-être l’habitude d’utiliser la commande source .venv/bin/activate pour activer votre environnement virtuel. Avec uv, c’est un peu différent. Votre .venv sera toujours créé, mais en utilisant uv, il se mettra par défaut dans votre environnement virtuel. Prenons un exemple.

Là où à l’époque vous auriez dû faire ce genre de commandes pour lancer votre script.

python -m venv .venv
source .venv/bin/activate
pip install requests
python main.py

Désormais, uv enlève la gestion de l’environnement virtuel de votre travail. Ainsi, les commandes ci-dessus seront remplacées par celles-ci.

1
2

uv add requests
uv run main.py

Lorsque vous ajoutez un nouveau paquet à votre projet (avec la commande uv add), uv se charge automatiquement de créer un environnement virtuel s’il n’existe pas déjà.

Ensuite, en lançant votre script via uv run, uv se mettra automatiquement dans votre environnement virtuel.

Installation de Python

Vous utilisiez peut-être pyenv pour installer vos différentes versions de Python. Avec uv, tout cela est de l’histoire ancienne !

Lorsque vous souhaitez lancer un projet avec une version de Python bien spécifique, vous avez plusieurs moyens de faire :

Utiliser le fichier .python-version
Créer un environnement virtuel : uv venv --python 3.11.6
Lancer une version de Python spécifique : uvx python@3.12

Ce que vous devez retenir, c’est que uv ne s’appuie pas sur une version globale de Python installée, mais essaiera toujours d’utiliser la version spécifique à votre projet.

Bon, je crois que vous en savez assez pour commencer votre initiation. Allons-y !

Installation

L’installation de uv est un jeu d’enfant. Vous avez plusieurs options, choisissez celle qui vous convient le mieux (n’hésitez pas à consulter la documentation officielle sur son installation si besoin) :

# Sur macOS et Linux - je vous recommande d'utiliser cela si possible
curl -LsSf https://astral.sh/uv/install.sh | sh

# Sur Windows (avec PowerShell)
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

# Avec pip (si vous avez déjà un environnement Python)
pip install uv

Une fois installé, vous pouvez le mettre à jour très simplement :

`1`	`uv self update`

Et voilà, uv est prêt à l’emploi !

Gérer les versions de Python avec uv

Une des fonctionnalités sympathiques de uv est sa capacité à installer des versions spécifiques de Python. Plus besoin de passer par le site officiel Python, de jongler avec pyenv ou d’autres outils.

Pour installer la dernière version stable de Python :

`1`	`uv python install`

Besoin d’une version particulière ? Pas de problème :

1
2

# Installer Python 3.9
uv python install 3.9

Vous pouvez ensuite utiliser cette version pour exécuter un script :

`1`	`uv run --python 3.9 python mon_script.py`

Comme je vous l’expliquais un peu plus haut, les versions de Python installées par uv ne sont pas disponibles “globalement” sur votre système via la simple commande python. Pour les utiliser, il faut passer par uv run --python <version>, ou les activer dans un environnement virtuel créé avec cette version spécifique.

uvx pour exécuter des packages à la volée

Vous connaissez peut-être npx dans le monde JavaScript ? uvx (le shortcut de uv tool run) est l’équivalent proposé par uv. Il permet d’exécuter une commande CLI Python (comme ruff, black, ipython, etc.) dans un environnement temporaire avec les dépendances spécifiées, sans polluer votre projet ou votre système.

Par exemple, pour lancer une version spécifique de ruff :

`1`	`uvx --python 3.12 ruff@0.9.6 check main.py`

Ou pour lancer ipython avec requests disponible temporairement :

`1`	`uvx --with requests -p 3.13 ipython`

Extrêmement pratique pour des one-shots ou pour tester des outils !

La gestion des projets avec uv

Bon, toutes ces commandes, c’est très sympa, mais j’imagine que vous vous demandez comment intégrer uv dans un nouveau projet, ou dans un projet existant.

Laissez-moi donc vous montrer toute la puissance de uv pour créer et gérer un projet Python.

Démarrer un nouveau projet

Pour initialiser un nouveau projet avec uv :

uv init

Cette commande va créer quelques fichiers pour vous :

.python-version : Spécifie la version de Python à utiliser pour ce projet (par exemple, 3.11).
main.py : Un fichier Python d’exemple.
pyproject.toml : Le fichier central pour la configuration de votre projet, y compris ses dépendances. C’est le standard moderne en Python.

Maintenant, voyons comment gérer nos dépendances.

Avec uv, le pyproject.toml devient votre source de vérité pour les dépendances.

Pour ajouter une nouvelle dépendance à votre projet :

`1`	`uv add requests`

Pour ajouter une dépendance de développement (uniquement pour le dev, comme ruff ou pytest) :

1
2

uv add ruff --dev
uv add pytest --dev

⚠️ Très important : La première fois que vous ajoutez une dépendance, uv va générer un fichier uv.lock. Ce fichier contient les versions exactes de toutes vos dépendances (directes et indirectes) qui ont été résolues. Ce fichier uv.lock est crucial et DOIT être commité dans votre repository GitHub. Il garantit que les versions de vos paquets soient les mêmes pour tout le monde, selon votre environnement de travail.

Une fois vos dépendances (notamment de dev) ajoutées, vous pouvez les utiliser avec uv run :

1
2

uv run ruff format .
uv run pytest

Pour supprimer un paquet :

# Pour une dépendance normale
uv remove requests

# Pour une dépendance de développement (notez le --group dev)
uv remove ruff --group dev

Dans le cas où vous utiliseriez uv en entreprise avec un index privé, vous pouvez aussi configurer cela !

Par défaut, uv utilise PyPI. Si vous travaillez dans un environnement d’entreprise (avec un Artifactory ou un autre index privé), vous pouvez configurer uv pour l’utiliser via le fichier pyproject.toml.

[[tool.uv.index]]
name = "votre-index"
url = "https://mon-artifactory.corp/api/pypi/mon-repo-virtual"
publish-url = "https://mon-artifactory.corp/api/pypi/mon-repo-local"
default = true

Ensuite, vous pouvez par exemple exporter des variables d’environnement pour vous authentifier.

# Les variables d'environnement doivent respecter le format suivant : UV_INDEX_{name}_USERNAME
# où {name} est le nom de l'index que vous avez défini dans votre fichier pyproject.toml
export UV_INDEX_VOTRE_INDEX_USERNAME="delia, antoine"
export UV_INDEX_VOTRE_INDEX_PASSWORD="cmVmdG**************************FJUjNw"

N’hésitez pas à consulter la documentation uv sur les index pour plus de détails.

Migrer un projet existant vers uv

Vous avez un projet avec un bon vieux requirements.txt ? La migration est assez simple :

Si vous n’avez pas de pyproject.toml, créez-en un (n’hésitez pas à utiliser celui fourni plus haut).
Lancez les commandes suivantes pour ajouter vos requirements dans votre pyproject.toml : uv add -r requirements.txt et uv add --dev -r requirements-dev.txt.
Une fois toutes les dépendances migrées, vous pouvez supprimer vos anciens fichiers requirements.txt.

Si vous utilisiez d’autres outils comme Poetry, il existe des outils de migration (comme par exemple : uvx migrate-to-uv).

Et voilà, votre projet est propulsé par uv !

Rejoindre un projet qui utilise déjà uv

Si vous clonez un projet qui est déjà géré par uv (il devrait donc y avoir un pyproject.toml et un uv.lock), la mise en place est d’une simplicité enfantine. Vous n’avez qu’à lancer :

uv sync

Cette commande magique va lire le fichier uv.lock et installer exactement les mêmes versions de tous les paquets qui y sont listés. N’est-ce pas beau tout ça ?

Build et publier votre projet

uv ne s’arrête pas là et propose aussi des commandes pour le build et la publication.

Pour construire votre package :

`1`	`uv build`

Pour publier sur PyPI (ou un index privé) :

1
2
3

uv publish
# Pour un index privé, vous pourriez avoir besoin de spécifier l'URL (sauf si déjà spécifiée dans votre pyproject.toml)
# uv publish --repository-url https://mon-artifactory.corp/api/pypi/mon-repo-local

Et pour tester rapidement si votre package fraîchement buildé s’installe et s’importe correctement :

1
2

# Remplacez <MON_PACKAGE> par le nom de votre paquet
uv run --with <MON_PACKAGE>-<VERSION>.whl --no-project --python -c "import <MON_PACKAGE>"

Et voilà ! Vous avez publié votre package en un clin d’oeil !

Nettoyer votre cache

Avec le temps, uv (tout comme pip) accumule un cache de paquets téléchargés. Alors certes, cela permet rapidement d’installer vos dépendances sur plusieurs projets, mais à la longue, cela pourrait prendre pas mal de place sur votre ordinateur. Pour le nettoyer, il suffit de lancer la commande suivante :

`1`	`uv cache clean`

Conclusion

Vous l’aurez compris, uv n’est pas juste “encore un autre gestionnaire de paquets”. C’est une véritable bouffée d’air frais dans l’écosystème Python.

La vitesse : C’est le premier argument qui frappe lorsqu’on l’utilise. Les installations, les résolutions, tout est incroyablement plus rapide que pip. Sur de gros projets, le gain de temps est phénoménal.
L’unification : uv regroupe des fonctionnalités qui nécessitaient auparavant plusieurs outils (pip, venv, pip-tools, voire pyenv pour des besoins basiques). Avoir une seule interface cohérente simplifie grandement le workflow.
La conformité : Les développeurs d’uv basent tous leurs choix sur les guidelines Python (ces fameux PEP). Vous pouvez donc être sûr que votre pyproject.toml respecte les standards modernes de packaging Python.
La fiabilité : Le système de lockfile (uv.lock) assure des builds reproductibles, un point essentiel pour le travail en équipe et l’intégration continue.

Depuis que j’utilise uv, mes interactions avec la gestion des dépendances Python sont devenues plus rapides, plus simples et plus agréables. C’est le genre d’outil qui, une fois adopté, vous fait vous demander comment vous faisiez avant.

Alors, si vous cherchez à moderniser votre utilisation de Python et à gagner en productivité (et en sérénité !), je ne peux que vous encourager à donner sa chance à uv. L’essayer, c’est très souvent l’adopter !

Références

Documentation officielle uv : https://docs.astral.sh/uv
Repo GitHub uv : https://github.com/astral-sh/uv
A year of uv: pros, cons, and should you switch? (bitecode.dev)
uv tricks (bitecode.dev)

Bonus : uv cheatsheet

Je vous mets ici une liste de commandes uv ultra pratiques. Une sorte de cheatsheet si vous préférez. N’hésitez pas à revenir la consulter au besoin !

# Update uv
uv self update

# Run a script with a specific Python version
uv run --python 3.12.3 main.py

# Quickly run a tool with a specific version
uvx --python 3.12 ruff@0.9.6 check

# Quickly run ipython with requests installed
uvx --with requests -p 3.13 ipython

# Update your project's version
uv version --bump [major/minor/patch]

# Clean the cache
uv cache clean

AWS Lambda : La phase d'INIT devient payante - faut-il s'alarmer ?

Tue, 13 May 2025 07:30:00 +0200

Introduction

Ah, les Lambdas. Probablement le service AWS que j’affectionne le plus ! En moins de temps qu’il ne faut pour le dire, elles permettent de créer un petit script ou carrément un backend API hosté dans le Cloud, et tout cela à moindre coût avec le “pay as you go”. Mais cela serait-il trop beau pour être vrai ?

Il y a quelques jours, AWS a annoncé une modification dans la manière dont la phase d’initialisation des Lambdas est facturée. À partir du 1er août 2025, cette phase sera systématiquement incluse dans le calcul de la durée facturée, et ce, pour toutes les Lambdas.

Si vous n’étiez pas au courant, sachez que jusqu’à présent, si vous utilisiez des fonctions Lambdas avec un code packagé en ZIP avec des runtimes managés par AWS (comme Python, Node.js, etc.), la durée de cette phase INIT n’était pas facturée. C’était un petit “cadeau” de la part d’AWS (plutôt sympa de leur part). Mais toutes les bonnes choses ont une fin, et il faudra maintenant payer ce temps d’initialisation de nos Lambdas.

Alors, cela va-t-il rendre l’usage des Lambdas trop cher ? Et comment faire en sorte de réduire au maximum cette partie d’initialisation ? Je vous propose aujourd’hui de répondre à toutes ces questions !

Comprendre le cycle de vie d’une Lambda

Avant de plonger dans la facturation, c’est l’occasion de se rappeler du cycle de vie d’une Lambda.

Pour simplifier la lecture, je ne rentrerai pas dans les détails des Lambda Extensions et de Lambda SnapStart.

Cela se compose de trois phases principales :

INIT : C’est l’étape du “démarrage à froid” ou cold start. Quand une nouvelle instance de votre fonction doit être créée pour répondre à une requête, Lambda prépare le terrain. Cette phase dure au maximum 10 secondes.
INVOKE : C’est là que votre code (le handler de votre fonction) est exécuté pour traiter la requête.
SHUTDOWN : Quand l’environnement d’exécution n’est plus utilisé pendant un certain temps, la Lambda se “shutdown” pour libérer les ressources. Si une nouvelle requête arrive, la Lambda devra de nouveau passer par la phase d’INIT.

Pendant la phase INIT, votre Lambda fait plusieurs choses :

Récupère votre code (depuis S3 pour un ZIP, ou ECR pour une image Docker).
Configure l’environnement avec la mémoire allouée, le runtime choisi, etc.
Démarre le runtime (Runtime INIT).
Exécute le code statique de votre fonction (tout ce qui est en dehors du handler, par exemple l’initialisation de variables globales ou de boto3) (Function INIT).

Le point clé à retenir de tout cela, c’est que la phase INIT ne se produit que lors d’un démarrage à froid (ce fameux cold start). Si une requête arrive alors qu’un environnement d’exécution est déjà “chaud” (prêt et réutilisé), cette phase est sautée, et on passe directement à l’INVOKE. C’est ce qu’on appelle un “démarrage à chaud” (warm start), qui est bien plus rapide.

AWS ne communique pas sur son calcul pour passer une Lambda “warm” à “cold”.

Le changement de facturation en détail

Actuellement, la facturation des Lambdas repose sur deux éléments :

Le nombre de requêtes.
La durée d’exécution de votre code, arrondie à la milliseconde supérieure (le coût de cette durée dépend de la mémoire allouée à la fonction).

Jusqu’au 1er août 2025, pour ces fonctions en ZIP avec runtime managé, la durée de la phase INIT n’était pas comptée dans la “Durée Facturée” (Billed Duration). On pouvait le voir dans les logs CloudWatch :

# Avant le 1er août 2025
# Notez que la Billed Duration est l'arrondie au supérieur
# de la Duration sans tenir compte de la Init Duration
REPORT RequestId: xxxxx   Duration: 250.06 ms   Billed Duration: 251 ms   Init Duration: 100.77 ms

# Après le 1er août 2025
# La Billed Duration est maintenant l'arrondie au supérieur
# de la Duration + la Init Duration
REPORT RequestId: xxxxx   Duration: 250.06 ms   Billed Duration: 351 ms   Init Duration: 100.77 ms

Comme vous pouvez le voir, AWS prendra maintenant en compte votre Init Duration en plus de la Duration pour réaliser son calcul de la Billed Duration.

Quel impact sur la facture ?

Alors tout ça, c’est bien beau, mais allons-nous tous finir ruiner par ce changement ?

Prenons un exemple pour y voir plus clair. Imaginons une Lambda en Python configurée avec 1024 Mo de mémoire, déployée dans la région eu-west-1 (Irlande).

Supposons les points suivants :

La Lambda reçoit 10 millions d’invocations par mois.
Le taux de cold start est de 1% (moyenne fournie par AWS), soit 100'000 démarrages à froid par mois.
La durée moyenne de l’invocation (Duration) est de 3 secondes.
La durée moyenne de l’initialisation (Init Duration) est de 1 seconde.
Coût par requête : $0.20 par million de requêtes.
Coût de la durée (x86) : $0.0000166667 par GB-seconde.

Détails des calculs

Calcul du coût AVANT le 1er août 2025 :

Coût des requêtes : 10 millions req * ($0.20 / 1 million req) = $2.00
Coût de la durée :
- Invocations “à chaud” (9.9 millions) : Durée facturée = 3 secondes.
- Invocations “à froid” (100 000) : Durée facturée = 3 secondes (INIT non facturée).
- Durée facturée totale (secondes) : (9'900'000 * 3 s) + (100'000 * 3 s) = 29'700'000 secondes + 300'000 secondes = 30'000'000 secondes.
- Go-secondes totaux : 30'000'000 secondes * (1024 Mo / 1024 Mo) = 30'000'000 Go-s.
- Coût Durée : 30'000'000 Go-s * $0.0000166667/Go-s = $500.00
Coût total mensuel (Avant) : $2.00 + $500.00 = $502.00

Calcul du coût APRÈS le 1er août 2025 :

Coût des requêtes : $2.00 (inchangé)
Coût de la durée :
- Invocations “à chaud” (9.9 millions) : Durée facturée = 3 secondes.
- Invocations “à froid” (100 000) : Durée facturée = 3 secondes (Duration) + 1 seconde (Init Duration) = 4 secondes.
- Durée facturée totale (secondes) : (9'900'000 * 3 s) + (100'000 * 4 s) = 29'700'000 secondes + 400'000 secondes = 30'100'000 secondes.
- Go-secondes totaux : 30'100'000 secondes * (1024 Mo / 1024 Mo) = 30'100'000 Go-s.
- Coût Durée : 30'100'000 Go-s * $0.0000166667/Go-s = $501.67
Coût total mensuel (Après) : $2.00 + $501.67 = $503.67

Dans ce scénario précis, l’augmentation est seulement de $1.67 par mois. C’est effectivement minime, et cela confirme la communication d’AWS. Mais faites quand même attention, car l’impact réel dépendra fortement de :

La mémoire allouée à vos Lambdas (plus de mémoire = coût par ms plus élevé).
La durée réelle de votre phase INIT.
Votre taux de cold start (peut être plus élevé si votre trafic est irrégulier).

Il est donc judicieux de vérifier avec vos propres chiffres !

Je vous mets ci-dessous un petit script qui vous permettra de rapidement tester cela de votre côté.

Script Python

def calculate_lambda_costs(
    total_invocations_per_month: int,
    cold_start_rate: float,
    average_invocation_duration_sec: float,
    average_init_duration_sec: float,
    allocated_memory_gb: float,
    cost_per_million_requests: float = 0.20,
    cost_per_gb_second: float = 0.0000166667,
):
    num_cold_starts = total_invocations_per_month * cold_start_rate
    num_warm_starts = total_invocations_per_month - num_cold_starts

    request_cost = (total_invocations_per_month / 1_000_000) * cost_per_million_requests

    # Duration cost BEFORE
    billed_duration_warm_starts_sec_before = num_warm_starts * average_invocation_duration_sec
    billed_duration_cold_starts_sec_before = num_cold_starts * average_invocation_duration_sec

    total_billed_duration_sec_before = billed_duration_warm_starts_sec_before + billed_duration_cold_starts_sec_before
    total_gb_seconds_before = total_billed_duration_sec_before * allocated_memory_gb / 1.024
    duration_cost_before = total_gb_seconds_before * cost_per_gb_second

    total_monthly_cost_before = request_cost + duration_cost_before

    # Duration cost AFTER
    billed_duration_warm_starts_sec_after = num_warm_starts * average_invocation_duration_sec
    billed_duration_cold_starts_sec_after = num_cold_starts * (average_invocation_duration_sec + average_init_duration_sec)

    total_billed_duration_sec_after = billed_duration_warm_starts_sec_after + billed_duration_cold_starts_sec_after
    total_gb_seconds_after = total_billed_duration_sec_after * allocated_memory_gb / 1.024
    duration_cost_after = total_gb_seconds_after * cost_per_gb_second

    total_monthly_cost_after = request_cost + duration_cost_after

    return total_monthly_cost_before, total_monthly_cost_after


def display_results(cost_before, cost_after):
    cost_difference = cost_after - cost_before
    print(f"\nMonthly cost increase: ${cost_difference:.2f}")
    if cost_difference > 0:
        percentage_increase = (cost_difference / cost_before) * 100 if cost_before > 0 else float("inf")
        print(f"Percentage increase: {percentage_increase:.2f}%")


if __name__ == "__main__":
    print("AWS Lambda Cost Calculator (before/after Init Duration pricing change)")
    print("Please enter the values for your scenario or press Enter to use default values.\n")
    default_invocations = 10_000_000
    default_cold_start_rate = 0.01  # 1%
    default_invocation_duration = 3.0  # seconds
    default_init_duration = 1.0  # seconds
    default_memory_gb = 1.024  # 1024 MB (1.024 GB)

    try:
        invocations_str = input(f"Total invocations per month (default: {default_invocations:,}): ")
        total_invocations_input = int(invocations_str) if invocations_str else default_invocations

        cold_start_rate_str = input(f"Cold start rate (e.g., 0.01 for 1%, default: {default_cold_start_rate}): ")
        cold_start_rate_input = float(cold_start_rate_str) if cold_start_rate_str else default_cold_start_rate

        invocation_duration_str = input(f"Average invocation duration in seconds (default: {default_invocation_duration}): ")
        invocation_duration_input = float(invocation_duration_str) if invocation_duration_str else default_invocation_duration

        init_duration_str = input(f"Average initialization duration in seconds (default: {default_init_duration}): ")
        init_duration_input = float(init_duration_str) if init_duration_str else default_init_duration

        memory_gb_str = input(f"Memory allocated to Lambda in GB (e.g., 0.512 for 512MB, default: {default_memory_gb}): ")
        memory_gb_input = float(memory_gb_str) if memory_gb_str else default_memory_gb

        cost_before, cost_after = calculate_lambda_costs(
            total_invocations_per_month=total_invocations_input,
            cold_start_rate=cold_start_rate_input,
            average_invocation_duration_sec=invocation_duration_input,
            average_init_duration_sec=init_duration_input,
            allocated_memory_gb=memory_gb_input,
        )

        display_results(cost_before, cost_after)

    except ValueError:
        print("\nError: Please enter valid numbers.")
    except Exception as e:
        print(f"\nAn unexpected error occurred: {e}")

Comment surveiller votre phase INIT et estimer l’impact ?

Un script, c’est bien, mais si vous avez un paquet de Lambdas à checker, vous risquez de vous épuiser à la tâche.

Heureusement, AWS nous donne quelques outils pour vérifier ça efficacement. En effet, comme vu plus haut, chaque Lambda va faire un REPORT de son Init Duration. Il nous est donc facile d’aggréger tout cela dans CloudWatch Logs Insights. Et cerise sur le gâteau, AWS nous offre même la requête qui va bien.

filter @type = "REPORT" and @billedDuration < (@duration + @initDuration) 
| stats sum((@memorySize/1000000/1024) * (@billedDuration/1000)) as BilledGBs, 
sum((@memorySize/1000000/1024) * ((ceil(@duration + @initDuration) - @billedDuration)/1000)) as UnbilledInitGBs, 
(UnbilledInitGBs/ (UnbilledInitGBs+BilledGBs)) as Ratio

Gardez en mémoire que CloudWatch Logs Insights vous est facturé $0.005 par GB de data scanné (source)

Plus qu’à lancer cette requête sur vos Lambdas (en utilisant le prefix /aws/lambda), et vous obtiendrez le résultat suivant :

BilledGBs	UnbilledInitGBs	Ratio
512.8007	86.6699	0.1446

Cette requête vous donne ainsi trois informations clés :

BilledGBs : Le total de Go-secondes actuellement facturé.
UnbilledInitGBs : Le total de Go-secondes consommés pendant la phase INIT qui n’étaient pas facturés auparavant.
Ratio : Le pourcentage que représentent ces Go-secondes INIT non facturés par rapport au total des Go-secondes consommés.

Dans notre exemple, la part du coût de l’INIT représente 14% de notre future facture ! Selon votre facture actuelle, cela pourrait être non négligeable.

Comprendre et optimiser sa Lambda

Bon, vous savez que vous allez devoir sortir la carte bleue. Mais n’y a-t-il pas un levier d’action pour diminuer cette augmentation dans votre facture ?

Je vous donne ici quelques conseils pour utiliser cette phase INIT au mieux et ainsi réduire vos futurs coûts.

Utiliser stratégiquement la phase INIT

Votre premier réflexe serait peut-être de vous dire qu’il faudrait enlever tout ce code INIT (celui hors du handler) pour le mettre dans votre handler. Comme ça, plus de facturation de l’INIT ! Mais non seulement vous ne feriez que déplacer le problème (car l’exécution de ce code vous sera tout de même facturé), cela sera encore pire, car maintenant, mêmes vos executions de Lambda “warm start” devront traiter ce code !

Car oui, rappelons que le code dans la phase INIT est exécuté uniquement pendant les “cold start”. C’est donc l’endroit idéal pour faire des opérations d’initialisation coûteuses qui pourront être réutilisées par les invocations suivantes (“warm start”). Cela est même recommandé par AWS. Ainsi, cette phase d’INIT est parfaite pour :

Importer des librairies ou dépendances lourdes.
Établir des connexions à d’autres services AWS (S3, DynamoDB, etc.) via les SDKs (boto3 pour Python).
Créer des pools de connexions à des bases de données.
Récupérer des paramètres ou des secrets depuis Systems Manager Parameter Store ou Secrets Manager.

Maximisez cette phase d’inititalisation pour réduire ainsi le temps d’exécutions des Lambdas qui elles tourneront en “warm start”.

Optimiser la taille du package

C’est souvent le levier le plus simple, car parfois, on importe un peu tout et n’importe quoi dans notre Lambda. Alors, soyez sûr de n’inclure que des dépendances strictement nécessaires. Veillez également à exclure tout ce qui est lié à votre environnement de développement (je ne vous dis pas le nombre de fois que j’ai trouvé un dossier node_modules ou tests dans des Lambdas…). Enfin, n’hésitez pas à consulter les articles d’AWS, car certains taclent directement le sujet des cold start.

Lambda SnapStart

Disponible pour les runtimes Java, .NET et Python, SnapStart est une fonctionnalité très intéressante pour combattre les “cold start”. Quand vous l’activez, Lambda prend un “snapshot” de l’environnement d’exécution initialisé après la première phase INIT. Pour les “cold start” suivants, la Lambda va restaurer ce snapshot au lieu de refaire toute la phase d’INIT, ce qui vous fera gagner pas mal de temps.

J’imagine qu’à la lecture de cette fonctionnalité, vous vous dites “mais enfin c’est super, je vais activer cette feature sur toutes mes Lambdas !”. Sauf qu’il y a quelques subtilités à connaître.

Premièrement, SnapStart n’est pour l’instant compatible qu’avec des versions bien précises de certains langages (Python 3.12 minimum, NodeJS pas supporté, …). Idem pour les régions, seulement 9 d’entre elles supportent cette feature pour Python et .NET. Enfin, cette feature n’est pas gratuite. Vérifiez bien le coût que cela pourrait engendrer si vous souhaitez l’activer sur vos Lambdas. ialisation).

Provisioned Concurrency

Si votre application a un trafic prévisible ou si la latence des cold start n’est pas envisageable, vous pouvez utiliser ce qu’on appelle la “Provisioned Concurrency”. Vous demandez à votre Lambda de garder un certain nombre d’environnements d’exécution pré-initialisés (chauds) en permanence.

Avantage : les requêtes arrivant sur ces instances provisionnées ne subissent jamais de cold start. La phase INIT est faite en amont, avant même la première requête.

Inconvénient : vous payez pour la durée pendant laquelle ces environnements sont provisionnés, qu’ils reçoivent des requêtes ou non. La phase INIT est d’ailleurs facturée lors de la pré-initialisation.

Là aussi, à vous de voir si cela vaut le coup d’activer cela sur certaines de vos Lambdas clées !

Conclusion

Le changement de facturation de la phase INIT de Lambda qui arrive le 1er août 2025 est avant tout une standardisation. Pour la majorité des Lambdas, cela signifie que la durée de cette phase sera désormais ajoutée à la durée facturée lors des cold start.

Même si l’impact financier sera probablement faible pour vous, c’est une excellente occasion de :

Comprendre le cycle de vie de vos Lambdas et ce qui se passe pendant l’initialisation.
Mesurer la durée de la phase INIT de vos fonctions critiques grâce aux outils CloudWatch.
Optimiser cette phase si nécessaire, en réduisant la taille de vos packages, en utilisant SnapStart, ou en envisageant la Provisioned Concurrency pour des cas spécifiques.

Alors, n’attendez pas le mois d’août ! Familiarisez-vous avec CloudWatch Logs Insights dès maintenant. Cela vous permettra d’identifier les Lambdas à optimiser en priorité et d’éviter toute mauvaise surprise sur votre facture AWS.

Comment j'ai automatisé la création de mon blog dans le Cloud

Tue, 04 Mar 2025 07:30:00 +0100

Le commencement et la fin

Quand j’ai envisagé de créer un blog pour la première fois, j’étais encore étudiant dans mon école d’ingénieurs. Et le monde des sites internets et des blogs était encore quelque chose de nouveau pour moi. Et lorsque je me suis finalement lancé dans l’aventure du blogging, c’est tout naturellement que je me suis tourné vers ce qui semblait être la meilleure solution à l’époque : WordPress.

Quoi que l’on en dise, WordPress est une solution relativement simple d’usage pour les débutants qui souhaitent créer leur premier site internet. Et ça tombe bien, car j’en faisais parti !

Alors, armé d’un tout nouveau compte chez OVH, j’ai pû mettre en ligne mon blog personnel en quelques cliques !

Et puis, quelques années plus tard, quand me vint l’idée de publier un blog dédié à des sujets professionels, là encore, j’ai fait appel à mon bon vieil ami WordPress.

Les mois passèrent, et l’idyle que je vivais avec WordPress commençait petit à petit à se ternir. Certes, rajouter des articles à travers l’UI de WordPress était pratique, mais pour ce qui était de gérer les backups, c’était une autre paire de manches. En plus, WordPress requiert une base de données pour fonctionner, ce qui rendait le tout très volumineux pour quelques articles, sans compter la facture qui venait avec.

Je me rendais alors compte que, pour un blog aussi simple, et avec si peu de visites, il y avait certainement un moyen d’améliorer les choses.

Le début d’un nouveau plan

Je vais vous raconter ici le cheminement qui m’a amené au renouveau de mon blog sur lequel vous vous trouvez aujourd’hui. Si vous êtes seulement intéressé par les détails techniques, vous pouvez avancer à la prochain section. Sinon, bonne lecture !

La découverte d’Hugo

Avant de me mettre en quête d’un nouvel outil pour mon blog, j’ai d’abord réfléchi à ce dont j’avais réelement besoin.

Mon blog était en fait assez rudimentaire : une page d’accueil qui listait les différents articles, pas de JavaScript tarabiscoté dans les parages, et aucun besoin d’un backend pour gérer une API. Au final, l’utilisation d’une base de données était-elle nécessaire ?

Il y avait aussi une chose importante à garder en mémoire. Je suis un ingénieur, ce qui fait de moi par définition, un bien piètre designer. Je voulais à tout prix éviter d’avoir à gérer le CSS de mon blog : je voualais me concenter sur le contenu, plutôt que sur le style.

J’ai donc commencé mes recherches, dans l’espoir de trouver un outil qui répondrait à ces critères. Et il ne m’a pas fallu bien longtemps avant de tomber sur la perle rare : Hugo.

À peine eus-je atterri sur le site d’Hugo que je fus accueilli par cet intriguant message : Le framework le plus rapide du monde pour générer des sites web. On peut dire que cela a piqué ma curiosité, et je me pressa d’aller fouiller dans la documentation. Et je n’allais pas être déçu.

Hugo se charge de convertir des articles au format markdown (comme l’on trouve sur les README de GitHub par exemple) vers le format HTML. Qui plus est, il existe une miriade de thèmes mis à disposition, ce qui me laissait l’embarras du choix, sans avoir besoin de designer quoi que ce soit !

Sans perdre une seconde, je m’empressai de convertir mon blog WordPress vers un site Hugo (j’ai utilisé pour ça un super petit script intitulé wordpress-to-hugo-exporter qui convertit une base de données WordPress en fichiers markdown avec l’arborescence requise pour Hugo).

Mon site Hugo était désormais prêt ! Il fallait maintenant trouver un moyen de l’héberger quelque part.

Un hébergeur à la hauteur : AWS

En même temps que je me creusais la tête pour trouver une alternative pour mon blog, j’ai eu une opportunité professionnelle qui m’a amené à travailler dans une entreprise spécialisée dans le Cloud, et plus particulièrement AWS.

À l’époque, le Cloud était tout nouveau pour moi. Mais j’en entendais tellement parler, que je voulais connaître la raison de cet engouement. Était-ce vraiment un “game-changer”, comme certains le disaient, ou était-ce encore un de ces mots-clés techniques qui faisait le buzz ?

Pour vous la faire courte, AWS était (et est toujours) absolument incroyable ! Ce n’était pas seulement la découverte d’un nouvel outil, il s’agissait là d’un changement de paradigme qui ne me ferait plus jamais aborder un problème de la même manière (si vous ne connaissez pas AWS et pensez que j’en fais trop, attendez de vous y mettre…).

Plus j’en apprenais sur AWS et la multitude de services qui le composait, plus je me disais : n’y a-t-il pas un moyen pour moi d’utiliser le Cloud pour mon blog ?

Avec cette idée en tête, je commençais à me renseigner sur toutes les options qu’offrait AWS. Et compte tenu de ma récente découverte d’Hugo, mon site n’avait ni besoin de PHP, ni d’une base de données pour fonctionner. Il s’agissait maintenant d’un site statique qui, à première vue, pouvait très bien être déployé dans un bucket S3.

Et non seulement AWS offre une documentation sur l’hébergement d’un site statique dans un bucket S3, mais le coût de stockage d’un site si léger ne représentait que quelques centimes.

J’avais trouvé là une manière simple et peu coûteuse d’héberger mon site.

Le dernier point qui me chiffonait, est que pour mettre en place tout cela, je devais créer un bucket AWS S3, le configurer convenablement, rajouter le CDN AWS CloudFront, prendre en compte les certificats via AWS ACM, et finalement créer une entrée DNS dans AWS Route53. Tant d’actions qui, si réalisées manuellement, pouvaient être difficiles à reproduire si jamais je venais à accidentellement supprimer mon compte AWS.

Il me fallait donc maintenant un moyen simple et robuste de configurer cette infrastructure.

Terraform à la rescousse

Quand vous commencez à apprendre le Cloud, vous allez généralement entendre parler d’Infrastructure as Code.

Le principe est simple : décrire son infrastructure Cloud avec… du code ! (oui, comme son nom l’indique).

L’avantage d’utiliser un outil d’IaC, c’est que vous allez pouvoir garder en mémoire les changements effectués sur votre infrastructure, et pouvoir ainsi avoir un historique de toutes les modifications effectuées (un peu comme vous pouvez le faire avec du code classique sur GitHub).

Imaginons par exemple que quelqu’un décide de changer la configuration d’un service AWS. Cette personne se connecte sur la console AWS et effectue ces modifications. Mais après plusieurs essais infructueux, cette personne décide de laisser tomber pour le moment, et de revenir en arrière. Mais voilà, elle n’est plus vraiment sûr de la manière dont le service était configuré au départ ! Et à moins d’avoir pris note de l’état initial, cette personne n’a plus qu’à deviner à coups de plusieurs essais l’état dans lequel remettre ce service.

Tout cela aurait pû être évité si le service avait initialement été configuré avec un outil d’Infrastructure as Code. Si tel avait été le cas, un petit coup de déploiement automatique aurait fait l’affaire !

Des outils d’IaC, il en existe un paquet. Mais comment ne pas parler du plus populaire, de celui qui a rendu cette pratique commune dans le milieu du Cloud : Terraform.

Terraform est donc un outil d’Infrastructure as Code avec une approche déclarative, ce qui signifie que c’est à vous de déclarer l’état dans lequel vous souhaitez déployer votre infrastructure. Pour cela, il faut utiliser un langage bien particulier : le hcl (pour HashiCorp Configuration Language). Voici par exemple la création d’un bucket S3 via Terraform.

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"

  tags = {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

Revenons maintenant à mon blog ! Terraform me semblait l’outil parfait pour configurer mon infrastructure qui accueillerait mon blog. Je n’avais plus qu’à passer par une étape d’architecture pour savoir de quels services AWS j’aurais besoin et comment les connecter entre eux, avant de mettre la main dans le code pour définir tout cela en langage Terraform.

Voici d’ailleurs le diagramme d’architecture que j’ai initialement crée pour l’occasion.

Tout cela était parfait, mais je me rendis vite compte d’une chose. À chaque fois que j’allais rajouter un article, ou que je devais modifier mon infrastructure, il me fallait cloner le projet sur mon ordinateur, et effectuer tout un tas d’opérations manuelles.

Autant vous dire que cela ne me plaisait pas du tout, et je comptais bien y remédier !

Oubliez les copier-coller avec GitHub Actions

Comme je le disais juste au-dessus, mon site était fin prêt. La dernière étape qui me manquait concernait le déploiement.

Pour l’instant, quand je voulais créer un nouvel article, il me fallait build le site Hugo à la main, et déplacer les fichiers générés dans mon bucket S3. Quel terrible gâchis de temps et d’énergie !

J’ai donc creusé le sujet des pipelines CI/CD afin de me rendre la vie plus simple (si le sujet vous intéresse, je vous conseille mon article sur la mise en place d’une stratégie CI/CD). Et bien que Jenkins essayait à tout prix de se distinguer, je suis parti sur ce qui semblait être le plus logique : GitHub Actions.

Les GitHub Actions sont en fait des pipelines CI/CD qui sont définies directement dans votre repository GitHub. Le gros avantage, est que vous n’avez pas besoin de créer un compte supplémentaire ou d’installer quoi que ce soit, tout est inclus ! En plus de ça, GitHub Actions utilise une syntaxe YAML très facile à comprendre (contrairement à Jenkins et son groovy des enfers !).

C’est donc assez facilement que j’ai pû créer une pipeline qui me reconfigure Terraform si mon infrastructure a été modifiée, et qui me build et deploy automatiquement mon blog sur mon bucket S3 en cas de modifications ou ajout d’un article.

Toutes les steps de la pipeline sont au vert, mission accomplie !

Côté technique : L’état actuel des choses

Mon blog est désormais automatisé et se déploie sur AWS automatiquement !

Si vous voulez plonger directement dedans, tout est publique sur mon repository GitHub : https://github.com/antoinedelia/cloud-optimist

Mais laissez-moi détailler un peu tout ça.

Structure du projet

La structure de mon projet est comme suit :

cloud-optimist/
├── .github/
│   └── workflows/
│       └── main.yml  # GitHub Actions
├── cloud/
│   └── ...  # Mon blog Hugo
├── terraform/
│   └── ...  # La configuration Terraform
└── README.md

Comme vous le voyez, je sépare ce projet en trois dossiers clés :

.github : contient le fichier main.yml qui définit les étapes CI/CD de la GitHub Actions
cloud : contient mon blog Hugo
terraform : contient toute l’infrastructure Terraform

La GitHub Actions

Ma GitHub Actions est assez simple, et se décompose en plusieurs étapes.

Les étapes de préparation

Regardons d’abord le haut du fichier.

name: 'Build and Deploy'

on:
  push:
    branches:
    - master
  pull_request:

jobs:
  build-and-deploy:
    name: 'Build & Deploy'
    runs-on: ubuntu-latest
    environment: production

    defaults:
      run:
        shell: bash
        working-directory: cloud

Ici, je dis à GitHub de lancer la pipeline uniquement sur la branch master, ou s’il s’agit d’une Pull Request. Je vous rassure, je ne déplois rien en production via une Pull Request. Vous verrez un peu plus bas, que cela me permet uniquement de build mon blog afin de tester que tout va bien, mais le déploiement ne sera effectué qu’une fois les changements mergés sur la branch master.

J’indique également à GitHub d’utiliser bash, et de se baser par défaut dans le dossier cloud.

Voyons maintenant la suite :

    steps:
    - uses: actions/checkout@v3
    - uses: dorny/paths-filter@v2
      id: filter
      with:
        filters: |
          web:
            - 'cloud/**'
          terraform:
            - 'terraform/**'

Cette première étape est cruciale si vous voulez accélérer vos temps de CI/CD ainsi qu’économiser de l’argent.

Je me sers de l’actions dorny/paths-filter qui me permet de détecter quels fichiers ont été modifiés lors du dernier commit. Dans mon cas, je regarde en particulier les dossiers cloud et terraform. Ainsi, si je ne détecte pas de changements côté Terraform, aucun besoin de lancer l’étape qui va reconfigurer mon infrastructure. Idem, si le dossier cloud est intact, inutile de build et deploy le blog. Cela vous sauvera quelques centimes liés au coût de transfert de fichiers vers AWS (pas la peine de me remercier !).

La section suivante parle d’elle-même.

    # Checkout the repository to the GitHub Actions runner
    - name: Checkout
      uses: actions/checkout@v2
      
    - name: Update Git Submodules
      working-directory: ./
      run: git submodule update --init --recursive

Je viens récupérer le contenu de mon repository et m’assure de mettre à jour les submodules. Cette dernière étape me servait du temps où j’utilisais les submodules pour mes thèmes Hugo. J’utilise désormais les Hugo Modules, et je pourrais donc zapper cette étape.

Les étapes Terraform

Passons à la partie Terraform :

    # Install the latest version of Terraform CLI and configure the Terraform CLI configuration file with a Terraform Cloud user API token
    - name: Setup Terraform
      if: steps.filter.outputs.terraform == 'true'
      uses: hashicorp/setup-terraform@v1
      with:
        cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

    # Initialize a new or existing Terraform working directory by creating initial files, loading any remote state, downloading modules, etc.
    - name: Terraform Init
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform init

    # Checks that all Terraform configuration files adhere to a canonical format
    - name: Terraform Format
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform fmt -check

    # Generates an execution plan for Terraform
    - name: Terraform Plan
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform plan

      # On push to master, build or change infrastructure according to Terraform configuration files
    - name: Terraform Apply
      working-directory: ./terraform
      if: steps.filter.outputs.terraform == 'true' && github.ref == 'refs/heads/master' && github.event_name == 'push'
      run: terraform apply -auto-approve

C’est déjà bien plus long ! Analysons ça étape par étape.

La première chose qui devrait attirer votre attention, c’est cette ligne :

`1`	`if: steps.filter.outputs.terraform == 'true'`

Vous vous rappelez, c’est ce qui permet de dire si des fichiers ont été modifiés dans le dossier terraform. Je vérifie donc ici si j’ai besoin de lancer ces étapes ou non.

Ensuite, je lance quelques commandes basiques de Terraform : un terraform init pour initialiser mon projet, un terraform fmt -check pour m’assurer que mon code est tout joli, et enfin un terraform plan pour voir les changements à effectuer.

Reste une dernière étape, et pas des moindres : le terraform apply -auto-approve, qui permettra de déployer les changements. Mais si vous êtes attentifs, vous remarquerez que j’ai rajouté deux conditions :

`1`	`github.ref == 'refs/heads/master' && github.event_name == 'push'`

Cela me garantit que cette étape ne sera uniquement lancée si l’action est un push sur la branch master. Ainsi, aucun risque de déploiement inopportun si je décide de travailler sur une autre branch ou sur une Pull Request. Ouf !

Les étapes Hugo et AWS

Maintenant que mon infrastructure est au point, il est temps de publier mon blog !

    - name: Build
      uses: actions/setup-node@v2
      if: steps.filter.outputs.web == 'true'
    - run: sudo wget https://github.com/gohugoio/hugo/releases/download/v0.142.0/hugo_extended_0.142.0_linux-amd64.deb -O hugo.deb
    - run: sudo dpkg --install ./hugo.deb
    - run: hugo

    - name: Deploy to AWS
      uses: jakejarvis/s3-sync-action@master
      if: steps.filter.outputs.web == 'true' && github.ref == 'refs/heads/master' && github.event_name == 'push'
      with:
        args: --acl public-read --follow-symlinks --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'eu-west-1'
        SOURCE_DIR: 'cloud/public/'

Comme pour Terraform, nous vérifions si des modifications ont été effectuées au niveau du blog.

`1`	`if: steps.filter.outputs.web == 'true'`

Ensuite, je récupère une version extended d’Hugo directement depuis la release GitHub, ici la version v0.142.0. Je l’installe et build mon site en lançant la commande hugo.

Cette étape pourrait être simplifiée avec l’utilisation de l’actions peaceiris/actions-hugo

Enfin, j’utilise l’actions jakejarvis/s3-sync-action (je me rends compte en écrivant cet article que cette actions a été archivée quelques jours plus tôt, aïe ! – je rajouterai un edit plus tard pour parler d’une alternative) pour déplacer mon blog vers mon bucket S3.

Bien sûr, il vous faudra stocker vos credentials au niveau de votre repository GitHub pour autoriser cette opération vers AWS, mais rien de bien sorcier !

La partie Terraform

Concernant la partie Terraform, je vais essayer d’être bref, car il n’y a rien de bien compliqué.

Une particularité dans mon cas, c’est que j’aime séparer mes fichiers .tf en fonction des services AWS utilisés, plutôt que d’avoir un unique fichier main.tf qui peut vite devenir difficile à lire. J’ai donc un fichier s3.tf pour les ressources liées au service S3, un cloudfront.tf pour tout ce qui est lié au service CloudFront, etc.

Un détail important, c’est qu’il est nécessaire de définir à minima la region us-east-1, car c’est dans cette region que vous devez créer vos certificats ACM. Pour le reste, toutes mes ressources sont créées dans la region eu-west-1. J’utilise pour cela les alias Terraform. Voici un exemple :

# La configuration par défaut : les ressources qui commencent par `aws_` utiliseront ce provider
provider "aws" {
  region = "eu-west-1"
}

provider "aws" {
  region = "us-east-1"
  alias  = "us_east_1"
}

resource "aws_s3_bucket" "site" {
  bucket        = var.bucket_name
  force_destroy = true
}

resource "aws_acm_certificate" "cert" {
  provider                  = aws.us_east_1  # Utilise le provider AWS dans us-east-1 via son alias
  domain_name               = var.domain_name
  subject_alternative_names = ["*.${var.domain_name}"]
  validation_method         = "DNS"
}

La partie Hugo

Mon blog Hugo se base sur le theme Stack. Il existe d’ailleurs un template GitHub qui vous permet en un clic de récupérer le squelette du blog, et de l’adapter selon vos envies, ou de tout simplement vous concentrer directement sur vos articles.

Pas grande chose de plus à dire sur cette partie, si ce n’est que je vous encourage à voir le fonctionnement des Hugo Modules, ce qui vous évitera de gérer vos thèmes via un submodule (et qui vous simplifiera la vie lors de la mise à jour du thème).

Pistes d’améliorations

Bien que je sois très satisfait du résultat final, j’ai noté quelques points qui pourraient être améliorés dans le futur.

D’abord, j’ai vu qu’Hugo dispose d’une commande deploy qui est capable de déployer directement un blog sur un bucket S3. Parfait ! Je dois donc creuser le sujet de Hugo Deploy.

Enfin, même si l’hébergement dans AWS est peu coûteux (moins de 2$ par mois), il n’en est pas moins gratuit. Or, il serait tout à fait possible d’utiliser les GitHub Pages pour rendre ce blog accessible, et profiter de GitHub comme hébergement (là-dessus, je suis un peu moins emballé, car je ne pourrais plus me la péter avec mes jolis diagrammes AWS…).

Conclusion

Et voilà, vous savez tout !

De mes débuts avec WordPress, qui, bien que pratique, présentait des faiblesses du point de vue backup, maintenance et déploiement.

De mes recherches pour trouver une stack technique parfaite : AWS, Terraform, Hugo et GitHub Actions, tout ça pour permettre un déploiement rapide et à moindre coût !

Quand je compare avec ce que j’avais à l’époque, je ne suis que trop heureux d’avoir sauté le pas !

Et vous aussi, vous avez maintenant toutes les informations pour créer un blog à vous, et déployer tout ça en un clin d’oeil !

Happy blogging !

Comment mettre en place une stratégie CI/CD pour onboarder plus de 100 projets Python en moins d'une minute

Sun, 19 Jan 2025 16:45:00 +0200

Nous savons tous que les pipelines CI/CD sont importantes. Il semble même impossible d’imaginer un monde où l’on déploie un projet en production sans vérifier la qualité de son code et sans s’assurer que des tests ont été effectués. De plus, pour permettre aux développeurs de se concentrer sur le développement, tout cela devrait être automatisé.

Eh bien, les choses ne sont pas toujours aussi simples.

Aujourd’hui, je vais vous partager comment nous sommes passés de l’absence de stratégie CI/CD à l’intégration de plus de 100 projets Python en moins d’une minute.

La réalité

Lorsque j’ai rejoint mon entreprise actuelle, j’ai constaté que nous gérions un grand nombre de projets Python. Mais quand j’ai essayé de vérifier la CI/CD de ces projets, c’était un peu le bazar. Certains projets avaient une configuration CI/CD, mais pas beaucoup. Et ceux qui en avaient une n’utilisaient pas les mêmes règles pour vérifier la conformité du code. Il était clair que la mise en place d’une CI/CD pour chaque projet était traitée comme un effort de dernier recours. Et, pour être honnête, cela se comprend.

En effet, bien que les pipelines CI/CD soient largement reconnues pour leur efficacité, leur mise en place s’avère souvent difficile.

Mais je savais que nous pouvions changer cela d’une manière ou d’une autre. Avant de sauter dans une stratégie à mettre en place, je voulais comprendre ce qui avait empêché cette mise en place en premier lieu.

Manque de permissions

La première chose que j’ai réalisée, c’est que tous les développeurs n’avaient pas le même niveau d’accès à notre instance Jenkins. Tandis que certains pouvaient créer de nouvelles pipelines pour leurs projets, d’autres ne le pouvaient pas. Dans les grandes entreprises, ce genre de scénario n’est pas rare.

Leçon apprise : un manque de permissions ne devrait pas être un obstacle pour utiliser une pipeline CI/CD.

Manque de connaissances

Lorsque les développeurs avaient la possibilité de créer un pipeline, certains ne le faisaient pas, simplement parce qu’ils n’avaient pas les connaissances nécessaires. Il faut préciser que notre entreprise utilise une instance Jenkins comme outil officiel de CI/CD. Cet outil, bien qu’ayant fait ses preuves, reste pour le moins difficile d’usage, notamment pour les jeunes développeurs qui sont souvent familiers avec d’autres outils CI/CD (comme GitHub Actions ou CircleCI). De plus, nous n’avions pas de documentation claire sur le processus à suivre pour créer une nouvelle pipeline. Ainsi certains développeurs, de peur de casser quelque chose, préféraient ne pas prendre de risques en évitant de toucher à Jenkins.

Leçon apprise : nous devons nous assurer que les personnes sans connaissances sur Jenkins puissent utiliser un pipeline CI/CD.

Manque de temps

Mettre en place une pipeline CI/CD au début d’un projet demande du temps, chose qui peut être négligée par les chefs de projets qui veulent expédier un produit aussi rapidement que possible. De plus, il est parfois difficile de quantifier le retour sur investissement d’une pipeline CI/CD. Et si cela est difficile à prouver comme étant bénéfique pour l’entreprise, cela finit dans la boîte “on s’en occupera plus tard”. Et nous savons tous que les tâches qui finissent dans cette boîte ne verront plus jamais la lumière du jour.

Leçon apprise : la mise en place d’une pipeline CI/CD doit être rapide et simple.

Manque de guidelines claires

Enfin, j’ai jeté un œil aux projets qui eux avaient une pipeline CI/CD. Ils fonctionnaient bien, mais je pouvais clairement voir qu’ils manquaient d’une vision commune. Certains utilisaient le même formateur de code (black), mais pas toujours avec la même longueur de ligne. Certains incluaient une étape de test, d’autres non. Nous avions donc des projets n’ayant pas la même qualité et conformité de code. Et cela pouvait potentiellement créer de la confusion pour un nouveau développeur, ne sachant pas quel standard suivre.

Leçon apprise : des guidelines claires de CI/CD doivent être mises en place.

La vision globale

Après avoir analysé ce qui pouvait poser problème, il est maintenant important de penser à une solution qui puisse résoudre tous ces points, tout en respectant les meilleures pratiques de l’entreprise et en utilisant les outils à notre disposition.

Formatting

La première étape serait d’utiliser un formateur pour s’assurer que chaque ligne de code dans notre base de code soit uniforme. Cela permet d’éviter que nous ayons des standards de code différents à travers nos projets.

Auparavant, nous utilisions black comme formateur. Mais après avoir entendu beaucoup de bien sur le nouvel outil à la mode, nous avons décidé de passer à ruff, offrant les mêmes avantages que black, mais avec une exécution plus rapide (entre autres).

Linting

L’étape suivante serait d’utiliser un linter pour détecter les problèmes potentiels dans notre code. Cela nous permet d’éviter la complexité dans notre code, ainsi que de repérer les mauvaises pratiques ou les problèmes de sécurité.

Dans le passé, j’utilisais beaucoup flake8. Mais étant donné que nous utilisions déjà ruff, et que celui-ci peut également agir comme un linter, la question ne se posait plus.

Il existe de nombreuses règles que ruff peut appliquer. Nous avons décidé d’en utiliser certaines par défaut, tout en laissant une certaine liberté aux développeurs selon les projets.

Tests unitaires

Les tests sont une partie critique du développement de tout projet. Ils assurent que nous livrons un code de qualité en production, tout en nous permettant de nous assurer que notre code fonctionnera correctement.

Nous avons décidé d’utiliser pytest pour exécuter ces tests. Le répertoire de code par défaut devrait s’appeler src, et tous les tests devraient être dans un dossier tests, avec des fichiers préfixés par test_.

Code Coverage

Étroitement liée aux tests unitaires, le code coverage nous permet de savoir jusqu’où notre code a été testé. Cela peut nous indiquer rapidement si nous avons suffisamment testé notre code, ainsi que nous indiquer les lignes restantes à couvrir.

Comme nous utilisions pytest, nous avons décidé d’utiliser pytest-cov pour générer un coverage report, car il s’intègre parfaitement avec pytest.

Nous avons fixé le seuil de couverture minimale à 50 %. En dessous, cela risquerait de négliger des portions importantes du code, tandis qu’au-dessus, cela pourrait décourager les développeurs d’écrire les tests nécessaires.

Jenkins Organization Folders

Les étapes de notre futur pipeline étaient prêtes. Il nous restait à trouver un moyen d’appliquer globalement cette pipeline à nos repositories Python. J’ai alors cherché un moyen de le faire facilement via Jenkins.

C’est là que je suis tombé sur les Organization Folders.

Les Organization Folders sont conçus pour des scénarios comme le nôtre : scanner automatiquement une organisation (comme une organisation GitHub), filtrer les repositories que vous voulez et appliquer une pipeline Jenkins à ces derniers.

Dans notre exemple, nous pouvons rechercher tous les repositories avec le topic “python” et les identifier comme projets Python. Ils seront alors automatiquement build par Jenkins. Si un nouveau repository est créé avec ce topic, il sera également pris en charge par Jenkins.

Ainsi, en moins de 5 secondes, votre projet peut être intégré, sans avoir à le créer dans Jenkins. Tout est fait automatiquement pour que vous puissiez vous concentrer sur votre code.

Exemples et documentation

Tout cela était génial, mais je redoutais un dernier obstacle. Que se passerait-il si les développeurs essayaient cette pipeline CI/CD, tout ça pour se rendre compte que leur projet ne passaient pas ces étapes ? Sans documentation claire pour résoudre ces problèmes, ils abandonneraient ou essaieraient de corriger ces erreurs plus tard, ce qui détruirait notre objectif initial.

Je savais donc que pour embarquer les gens dans ce processus, il fallait fournir une documentation claire avec des exemples concrets, pour qu’ils puissent avoir les clés pour résoudre ces erreurs.

En particulier pour l’étape des tests unitaires, car je ne sais que trop bien que cela représente une tâche décourageante à démarrer. J’ai donc préparé un projet à l’avance avec des tests unitaires déjà prêts. N’importe qui pouvait ainsi s’en inspirer, ou direcement recopier certaines parties complexes (par exemple, le mock des appels API boto3).

La dernière étape serait de faire une présentation sur tout ce que je viens d’évoquer. Cela était essentiel pour expliquer et donner du sens à ce projet, pour que les développeurs comprennent réellement l’intérêt de tout cela, tout en s’assurant qu’ils aient toutes les clés pour être autonomes. Enfin, cela serait également l’occasion de répondre à de nombreuses questions, et assurer que tout le monde comprenne le fonctionnement de cette nouvelle pipeline.

Ce que nous avons aujourd’hui

Du point de vue d’un développeur, tout ce qu’il doit faire pour ajouter une pipeline CI/CD à son projet Python est d’ajouter le topic python à son repository et de s’assurer qu’un fichier pyproject.toml est bien créé à la racine du projet.

Ces deux exigences permettent à Jenkins de savoir quels projets il doit prendre en compte. Le fichier pyproject.toml est en effet indispensable pour les étapes de ruff dans la pipeline.

Une fois cela fait, le projet Python vérifiera maintenant les problèmes de formatage, les erreurs de linting, la validation des tests unitaires et la couverture du code.

Au final, nous pouvons maintenant mettre en place des pipelines CI/CD en moins d’une minute, que ce soit pour un nouveau projet ou un projet existant !

Quelques défauts

Bien que cela simplifie beaucoup de choses, il reste encore des améliorations possibles.

La pipeline ne peut pas être imposée

Actuellement, cette pipeline CI/CD ne peut pas être imposée, car les développeurs peuvent simplement retirer le topic python. Et bien que cela soit acceptable au début (car nous ne voulons pas bloquer les développeurs dans leur travail), l’objectif reste de s’assurer que nous appliquons les mêmes bonnes pratiques à tous les projets Python.

Cela pourrait être résolu à l’avenir par l’utilisation des GitHub Rulesets.

Ces règles fonctionnent à peu près de la même manière que les règles de protection des branches, sauf que vous définissez ces règles au niveau de votre organisation GitHub.

De cette manière, nous pourrions protéger nos branches principales pour tous nos repositories qui matchent à des “custom properties” et ainsi exiger qu’ils valident leur pipeline CI/CD avant de pouvoir merger.

Les étapes de la pipeline peuvent être ignorées

Le fichier pyproject.toml est utilisé pour dire à ruff quel format il doit appliquer ou quelles règles suivre.

Et comme nous utilisons actuellement le pyproject.toml dans chaque repository, un développeur pourrait simplement enlever ces règles, contournant ainsi toutes les directives que nous essayions d’appliquer au départ.

Encore une fois, bien que nous permettions cela pour l’instant afin de prendre en compte les nombreuses corrections à apporter, à terme, nous aimerions vouloir empêcher cela.

Nous pourrions soit utiliser un fichier pyproject.toml commun et fixe, soit l’ajouter dans le fichier CODEOWNERS de GitHub pour nous assurer qu’il ne puisse être modifié sans une approbation stricte.

Et après ?

Avec tout cela en place, nous pouvons maintenant penser à l’évolution de cette pipeline.

Par exemple, notre entreprise dispose d’une instance SonarQube. Nous serions intéressés d’ajouter une étape qui pourrait analyser chaque projet à la recherche de mauvaises pratiques.

Nous explorons aussi l’utilisation de mkdocs, pour que les projets puissent partager un style commun pour la documentation.

Et une de mes évolutions préférées, nous pourrions explorer l’utilisation de uv pour installer les dépendances, car il est beaucoup plus rapide que ce bon vieux pip !

Vous avez également peut-être remarqué que, bien que j’aie parlé de CI/CD tout au long de cet article, à aucun moment nous avons parlé d’une étape qui, eh bien, déploie quelque chose (ce qui nous laisse avec une pipeline CI). Nous réfléchissons déjà à un moyen de build/deploy des packages Python vers notre gestionnaire de dépôt Artifactory, ce qui en ferait enfin une vraie pipeline CI/CD !

Enfin, nous n’avons abordé que Python dans cet article, mais la même logique pourrait s’appliquer à d’autres types de projets. Par exemple, nous travaillons également sur une pipeline CI/CD pour Terraform.

Conclusion

En abordant les problèmes de permissions, les lacunes en matière de connaissances Jenkins et l’absence de guidelignes, nous avons construit une stratégie CI/CD unifiée qui prend désormais en charge plus de 100 projets Python. Cela prouve qu’avec la bonne approche, l’automatisation est réalisable pour toute organisation.

Cela a été un long mais enrichissant parcours !

J’espère que cet article a montré la valeur des pipelines CI/CD, vous a aidé à comprendre ce qui pourrait empêcher son application et vous a donné quelques idées sur la manière de mettre en place une stratégie similaire dans votre organisation !

Postman pre-request script, plus besoin de regénérer votre access token

Mon, 16 May 2022 22:49:13 +0200

L’une des tâches les plus courantes lorsque vous travaillez avec des APIs est de les “pinger” pour vérifier si elles fonctionnent comme prévu (aussi connu sous le nom de : tests).

Un des outils les plus simples et utiles sur le marché est Postman, un client API qui vous permet de faire des requêtes à n’importe quelle URL, en utilisant toutes les méthodes que vous pouvez imaginer. Vous pouvez même spécifier des headers HTTP, ce qui est pratique si vous devez passer un token d’accès (access token) dans la requête pour authentifier votre appel API.

Et c’est là que j’ai commencé à rencontrer un problème. Pas un véritable problème, mais quelque chose d’encore plus frustrant pour un ingénieur : la répétition.

En fait, pour transmettre cet access token à la requête, vous devez d’abord le générer (généralement via un autre appel API). Le hic, c’est que cet access token est éphémère, et expire après une heure.

Alors, qu’est-ce que cela implique ? Eh bien, chaque heure, avant de faire une nouvelle requête à votre API, vous devez d’abord faire une requête pour obtenir un nouveau token, copier le résultat, et le coller dans l’en-tête de la requête initiale. En tout, cela vous fera perdre 10 secondes.

Ouf ! Vous imaginez un peu ? 10 secondes ?! Tout ce que l’on pourrait accomplir si l’on arrivait à récupérer ce temps précieux !

Mais avec Postman, je savais que ce problème pouvait être résolu d’une manière ou d’une autre. Et en effet, après une simple recherche sur le web, je suis tombé sur la solution parfaite : Pre-request script.

L’idée est assez simple : exécuter un script avant chaque requête. Voilà.

Comment cela peut-il nous aider, demandez-vous ? Eh bien, nous pouvons maintenant écrire un petit morceau de code qui va récupérer un nouvel access token et le stocker dans les variables de la collection dans laquelle nous nous trouvons. Ensuite, nos requêtes feront toujours référence à cette variable pour s’assurer qu’elles disposent d’un token à jour.

Laissez-moi vous montrer un exemple que j’ai utilisé dans l’un de mes projets où j’avais besoin de récupérer un access token d’AWS Cognito avant chaque requête.

pm.sendRequest({
    url: "https://YOUR_COGNITO_DOMAIN_NAME_HERE.auth.eu-west-1.amazoncognito.com/oauth2/token",
    method: 'POST',
    header: {
        'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: {
        mode: 'urlencoded',
        urlencoded: [
            {
                key: "grant_type",
                value: "client_credentials"
            },
            {
                key: "client_id",
                value: "YOUR_CLIENT_ID_HERE"
            },
            {
                key: "client_secret",
                value: "YOUR_CLIENT_SECRET_HERE"
            },
            {
                key: "scope",
                value: "YOUR_SCOPE_HERE"
            }
        ]
    }
}, (err, res) => {
    pm.collectionVariables.set("access_token", res.json().access_token)
});

Comme vous pouvez le voir, c’est assez simple, et cela peut probablement être appliqué à n’importe quel projet nécessitant une authentification OAuth.

J’espère que cela vous a été utile et surtout n’oubliez pas : si vous pouvez économiser 10 secondes, faites-le !

À Propos

Sun, 06 Mar 2022 00:00:00 +0000

Je m’appelle Antoine Delia et je suis Cloud & DevOps Engineer.

Sur ce blog, j’ai envie de parler de nombreux sujets liés au Cloud et à la culture DevOps. Ce sont des sujets qui me passionnent, et j’aime pouvoir transmettre mes connaissances avec une touche de légèreté, voire d’humour.

J’espère que cela vous plaira !

Compétences :

Cloud (AWS)
Infrastructure as Code (Terraform / Serverless Framework / CloudFormation)
Scripting (Python, Bash)
CI/CD (GitHub Actions, Jenkins)

Projets et réalisations :

The Cloud Optimist (le blog sur lequel vous vous trouvez) : blog Hugo déployé via GitHub Actions sur AWS, infra managée par Terraform
Introduction au Serverless : séminaire virtuel (https://www.youtube.com/watch?v=nCGTWbUsfN4)
3 certifications AWS (Architect Associate / Developer Associate / Cloud Practitioner)
1800+ points sur StackOverflow
Marathon de Toulouse 2025 couru en 03:58:44
TOEIC (965/990)

La Méthode du Canard en Plastique - pourquoi ça marche ?

Wed, 26 Jun 2019 22:49:13 +0200

La programmation est un art complexe. Vous êtes un véritable architecte et votre mission est de concevoir, construire, décorer et entretenir une application, un peu comme vous le feriez pour une maison.

Cependant, une difficulté émerge : vous devez communiquer des informations à une machine à travers des langages de programmation pour que tout fonctionne. Alors que vous ne parlez pas à vos meubles pour les placer dans votre maison, n’est-ce pas ? N’est-ce pas ?

Cette petite différence est cruciale, car il arrive parfois que vous rencontriez un problème sans savoir pourquoi il est là. Vous avez développé cette chose tellement parfaitement qu’elle ne devrait pas échouer. Et pourtant, voilà un bug, et vous ne savez pas pourquoi.

La première chose à faire est bien évidemment d’accuser l’ordinateur. Après tout, vous savez ce que vous faites, il n’y a aucune raison pour que vous ayez écrit quelque chose de travers. C’est probablement cet imbécile d’ordinateur qui vous fait encore passer pour un idiot. Mais la vérité est difficile à avaler.

La machine fait exactement ce que vous lui dites de faire.

– Bill Gates, probablement

Que vous le vouliez ou non, votre ordinateur est bête. Il récupère sans réfléchir l’information que vous lui fournissez et l’exécute. Et s’il échoue, c’est sans aucun doute de votre faute. Je sais que ça fait mal, croyez-moi. Mais ne vous inquiétez pas trop, cela est arrivé à chacun de nous, et au final, tout le monde s’en est sorti.

Maintenant, tout dépend de vous. Vous savez que vous avez fait quelque chose de travers, mais vous ne parvenez pas à savoir quoi. Que faire ? Faut-il chercher des réponses sur StackOverflow ? Démissionner de votre poste car vous n’êtes clairement pas à la hauteur ? La réponse est simple.

La première étape quand vous êtes bloqué, est de faire appel à la sagesse du canard.

Je sais ce que vous pensez en ce moment : Qu’est-ce que tu es en train de fumer et où puis-je trouver ça ? Mais croyez-moi, cette histoire de canard n’est pas une hallucination, c’est même LA meilleure façon de vous aider.

Ne vous inquiétez pas cependant, vous n’aurez pas besoin de conduire à la ferme la plus proche et voler un canard pour appliquer ce conseil. Dans notre cas, un canard en plastique est tout ce dont nous avons besoin.

Une fois que vous en avez un et que vous le placez sur votre bureau, la seule chose qu’il vous reste à faire est de lui parler. Allez-y, ne soyez pas timide. Et expliquez-lui ce qui se passe avec votre code.

Je préfère vous en parler tout de suite pour que vous ne soyez pas choqué quand vous serez confronté à la vérité, mais le canard ne vous répondra pas. C’est déchirant, je sais. Cependant, il est l’auditeur parfait et sa patience est bien au-dessus de celle de n’importe quel autre être humain, contrairement à vos collègues. De plus, le canard ne jugera jamais vos erreurs. Il est gentil et compréhensif.

Et plus vous lui expliquerez vos problèmes, plus vous réaliserez ce qui n’allait pas dans votre code. En effet, le fait d’expliquer correctement au canard ce que vous tentez de faire mettra en évidence une petite incohérence entre ce que vous avez fait et ce que vous essayez d’accomplir. Petit à petit, vous serez bientôt capable de repérer la ligne exacte de code qui causait tous vos problèmes et de la corriger comme un pro.

Et c’est pour ça que le canard est si utile. Non seulement vous laissez vos collègues travailler en paix, mais cet exercice vous oblige à prendre du recul par rapport à votre code afin de pouvoir l’expliquer à quelqu’un qui n’a aucune idée de ce qui se passe.

Cet effort de mettre des mots sur le comportement attendu et ce que vous avez pu accomplir jusqu’à présent mettra en lumière toutes les erreurs potentielles que vous auriez pu commettre pendant le développement, des choses qu’on ne voit pas quand on passe huit heures à regarder son code sans s’arrêter.

En décrivant ce que le code est censé faire et en observant ce qu’il fait réellement, toute incohérence entre ces deux devient apparente.

– Stephen J. Baker

Alors, la prochaine fois que vous serez bloqué, ne dérangez pas vos collègues, économisez votre connexion internet et demandez simplement au canard !

Si vous souhaitez en savoir plus sur cette méthode, je vous conseille vivement de jeter un œil au site qui a inspiré ce billet : https://rubberduckdebugging.com/.

FizzBuzz, la façon la plus simple et efficace de tester un développeur

Mon, 27 May 2019 13:35:55 +0200

Lorsque je suis sorti de mon école d’ingénieur, j’ai passé beaucoup d’entretiens dans l’espoir d’obtenir un poste de développeur. Mes expériences s’étant limitées à quelques stages, je redoutais cette partie de l’entretien où je devais me lever et résoudre un exercice de code sur un tableau blanc, ou même simplement répondre à quelques questions techniques. Je me trompais.

Aucun entretien ne m’a testé sur mes compétences en développement.

J’aurais pu mentir tout au long de l’entretien et tout de même obtenir le poste.

Pour être honnête, je ne fais pas partie de ceux qui louent les questions techniques comme s’il s’agissait d’une formule magique pour détecter les bons développeurs. Je préfère penser qu’une personne avec un bon tempérament, passionnée et humainement agréable est beaucoup plus intéressante qu’un “je-sais-tout” qui ramène toujours sa science à la table sans vouloir entendre l’avis des autres. On peut combler un manque technique, mais on ne peut pas améliorer un mauvais caractère.

Cela étant dit, je crois qu’il est obligatoire de vérifier à minima la manière de penser de quelqu’un lorsqu’il est confronté à un problème. Parce qu’au final, c’est ce qu’il fera la plupart du temps : résoudre des problèmes. En ce sens, il est crucial de voir comment quelqu’un va réagir face à un problème. Va-t-il fuir ? Va-t-il immédiatement demander de l’aide ?

C’est là qu’intervient le test FizzBuzz.

Cet article a été inspiré par la vidéo de Tom Scott que je vous recommande vivement de regarder si ce sujet vous intéresse.

L’idée de FizzBuzz est simple. Vous devez énumérer les nombres à haute voix en commençant par 1 jusqu’à 100. Mais, si le nombre est un multiple de 3, vous devez dire “Fizz” à la place. De même, si le nombre est un multiple de 5, vous devez dire “Buzz”. Maintenant, vous vous demandez peut-être : “Que faire si c’est un multiple de 3 et de 5 ?”. Eh bien, vous devrez simplement dire “FizzBuzz”. Générique de fin.

En lisant ce test simple, vous pourriez vous demander pourquoi il devrait être utilisé, car à première vue, même un stagiaire pourrait le résoudre assez facilement. Eh bien, c’est ce que je pensais aussi, jusqu’à ce que je tombe sur l’article de Jeff Atwood à ce sujet, où il explique être surpris de voir que ce problème donnait beaucoup de mal à des candidats, seniors compris.

Alors, essayons de le résoudre ensemble !

Dans la plupart des entretiens techniques, vous avez généralement le choix du langage de programmation avec lequel vous souhaitez résoudre un problème (voir même d’écrire en pseudo-code). Pour ce billet, j’utiliserai Python.

Avant toute chose, créons une boucle simple qui affiche tous les nombres de 1 à 100.

# Premier piège ici, range exclut le dernier nombre que vous lui passez.
# Ici, nous commençons bien à 1, et finissons à 100.
for i in range(1, 101):
    print(i)

On commence bien ! Maintenant, revenons à l’énoncé original : si le nombre est un multiple de 3, on affiche “Fizz”, si c’est un multiple de 5, on affiche “Buzz”. Ajoutons ces conditions.

for i in range(1, 101):
    if i % 3 == 0:
        print('Fizz')
    if i % 5 == 0:
        print('Buzz')
    if i % 3 != 0 and i % 5 != 0:
        print(i)

Prenons un moment pour voir ce qu’on a fait ici. Pour vérifier si un nombre est un multiple de 3, nous utilisons le modulo avec le symbole %. Nous faisons la même chose pour les multiples de 5. Enfin, si le nombre n’est ni un multiple de 3 ni de 5, on l’affiche simplement.

Ainsi, on obtient exactement ce que l’on veut !… Sauf quand un nombre est un multiple de 3 ET de 5. Dans ce cas, les mots Fizz et Buzz ne sont pas affichés sur la même ligne ! Nous devons donc prendre en compte ce cas en ajoutant une nouvelle condition, et empêcher les deux premiers if de se déclencher.

for i in range(1, 101):
    if i % 3 == 0 and i % 5 != 0:
        print('Fizz')
    if i % 5 == 0 and i % 3 != 0:
        print('Buzz')
    if i % 3 == 0 and i % 5 == 0:
        print('FizzBuzz')
    if i % 3 != 0 and i % 5 != 0:
        print(i)

Ça fonctionne enfin ! Mais à quel prix ? Ce code est un vrai désordre. Et ce n’est en aucun cas un code facile à maintenir. Prenons cet exemple : que se passerait-il si nous voulions maintenant afficher le mot Fizz pour les multiples de 2 au lieu de 3 ? Nous devrons changer cette valeur à 4 endroits différents dans le code pour que cela fonctionne.

Cela peut sembler trivial avec un code aussi minimaliste, mais imaginez ce qui se passerait si cela arrivait dans un projet bien plus grand. Ce code est sujet à erreurs, complique sa maintenabilité et rend presque impossible l’ajout de nouvelles fonctionnalités facilement.

Essayons une autre approche pour rendre ce code plus élégant ! Déclarons d’abord une variable qui sera la valeur que nous voulons afficher à la fin. On la laisse vide pour l’instant. Chaque fois que nous avons une condition qui correspond, nous ajoutons simplement le mot correspondant à la variable. À la fin, vérifier si la variable est vide nous indiquera si nous devons l’afficher ou plutôt afficher le nombre.

Voici ce que cela donne.

for i in range(1, 101):
    result = ''
    if i % 3 == 0:
        result += 'Fizz'
    if i % 5 == 0:
        result += 'Buzz'
    print(result or i)

C’est déjà beaucoup plus clair ! Non seulement nous avons réduit le nombre de lignes de moitié, mais nos vérifications if sont désormais limpides et ne laissent aucune place à l’interprétation. De plus, nous pouvons facilement changer la valeur de n’importe quel nombre si nécessaire sans avoir à chercher toutes ses occurrences. Enfin, si nous devons ajouter une autre condition (pour les multiples de 7 par exemple), il nous suffira d’ajouter deux nouvelles lignes sans toucher au reste du code !

Nous voyons enfin en quoi ce simple test FizzBuzz est si intéressant. Il nous a permis de tester la capacité d’une personne à utiliser des principes algorithmiques simples, mais aussi de vérifier sa manière de penser lorsqu’elle est confrontée à un problème, et si elle est capable de produire un code qui pourra être facilement maintenu dans le futur.

En résumé, FizzBuzz est un bon moyen de différencier un développeur d’un bon développeur.

Liens

Mon, 01 Jan 0001 00:00:00 +0000

Recherche

Mon, 01 Jan 0001 00:00:00 +0000