Date de naissance: 27 Août, 1993
Addresse: 4 rue à moissy, moigny sur école, 91490, France
E-mail:
guyot.alexis91@gmail.com
Téléphone: +33 6 32 27 14 56
Je m’appelle Alexis, passionné par le cloud, le MLOps et les projets techniques structurants. Mon profil hybride associe une expertise technique avancée à des compétences solides en pilotage de projets.
Mon parcours m’a conduit à prendre la responsabilité du Pôle Scientifique, où j’ai piloté les infrastructures et services IT destinés à la recherche.
Ce rôle m’a placé à l’interface entre les entités scientifiques, les directions (dont le Secrétariat général) et les équipes techniques, avec la supervision opérationnelle d’une équipe IT pluridisciplinaire (systèmes, infrastructures, réseaux), dans un contexte de transformation numérique.
Parmi les projets majeurs que j’ai menés, la plateforme Onyxia occupe une place centrale. J’ai assuré son déploiement, son adaptation et sa gestion opérationnelle sur plus de deux ans, pour l’ensemble des entités scientifiques du groupe (ENSAE, ENSAI, CREST, CEPE).
Basée sur Kubernetes, cette infrastructure cloud permet à des centaines d’utilisateurs d’accéder à des ressources mutualisées (GPU, stockage, outils open source) dans un environnement sécurisé, automatisé (Helm, ArgoCD, Gitea, S3) et interopérable (authentification Keycloak).
Ce projet a mobilisé à la fois une expertise technique pointue et une forte capacité à fédérer les parties prenantes autour d’une vision commune, en instaurant la confiance nécessaire pour faire évoluer les usages.
Aujourd’hui, je souhaite aller plus loin dans cette logique de pilotage en complétant mon expertise par la certification PMP.
Ma candidature a été validée par le PMI et l’examen est prévu pour septembre 2025, afin de structurer mes compétences de gestion de projet autour des standards internationaux.
Curieux, rigoureux et motivé par la création de valeur tangible, je suis prêt à contribuer à des projets d’envergure mêlant cloud, IA, stratégie IT et management d’équipe, en France ou à l’international.
CV sur le Cloud
Site web hébergé chez AWS sans serveur (https://alexisguyot.click)
J'ai entrepris ce projet peu après avoir obtenu ma certification AWS Cloud Practitioner. Pour la conception du frontend, j'ai opté pour l'utilisation d'un modèle HTML/CSS que j'héberge sur un stockage AWS S3.
Le chargement du site Web déclenche une fonction AWS Lambda qui augmente de un le nombre de visiteurs dans une table DynamoDB et renvoie le nouveau nombre de visiteurs au site Web. Pour empêcher tout accès non autorisé à la fonction, une URL de fonction Lambda CORS a été configurée pour n'accepter que les requêtes du domaine : "https://alexisguyot.click".
Chaque modification apportée déclenche un processus d'intégration continue et de déploiement continu (CI/CD) via AWS CodePipeline et GitHub.
AWS Route 53 prend en charge la gestion du nom de domaine, la distribution est globalement distribuée grâce à AWS CloudFront qui va mettre en cache le site sur des serveurs Edge dans le monde entier.
AWS Certificate Manager gère les certificats SSL/TLS pour une communication sécurisée. De plus, des permissions OAC ont été configurées sur S3, garantissant que tout le trafic passe obligatoirement par CloudFront, renforçant ainsi la sécurité.
Speedlight
Application Web de calcul
Cette application web permet de calculer le temps estimé pour parcourir une distance donnée en utilisant divers moyens de transport créés par l'humanité, tout en le comparant à la vitesse de la lumière.
L'interface utilisateur repose sur une simple page HTML/CSS hébergée sur AWS Amplify. Les utilisateurs entrent simplement la distance en kilomètres qu'ils souhaitent calculer.
En coulisses, pour la partie back-end : le navigateur communique avec une API backend publique, construite à l'aide de Lambda et d'API Gateway. Cette API effectue les calculs, fournissant ensuite les résultats à l'utilisateur.
La fonction Lambda est rédigé en python et utilise boto3 pour intéragir avec d'autres ressources AWS. Celle-ci va également enregistrer chaques calculs effectués par les utilisateurs dans une base de donnée DynamoDB.
Pour des raisons de coût, l'application réside désormais sur AWS S3 plutôt que via AWS Amplify.
Application Web
Application Web sans serveur
Ce projet a été conçu dans le but d'affiner mes compétences et d'explorer de nouvelles perspectives.
Le frontend de l'application web est pré-construit, c'est une interface utilisateur HTML qui permet d'ajouter des points GPS sur une carte, tandis que le backend communique avec un service web RESTful pour enregistrer ces coordonnées dans une base de données DynamoDB.
AWS Amplify assure le déploiement continu et l'hébergement des ressources web statiques, incluant HTML, CSS, JavaScript et images.
Le JavaScript exécuté dans le navigateur envoie et reçoit des données d'une API backend publique conçue en utilisant Lambda et API Gateway.
L'application web prend également en charge la fonctionnalité d'inscription et d'authentification des utilisateurs, via Amazon Cognito, sécurisant ainsi notre API backend.
Enfin, DynamoDB offre une couche de persistance où les données peuvent être stockées par la fonction Lambda de l'API.
Terraform Speedlight
Déploiement d'infrastructure via terraform
Pour approfondir mes compétences en Infrastructure as Code
(IaC), j'ai entrepris de rendre mon projet "Speedlight" entièrement
déployable via Terraform. Cette démarche vise à permettre à quiconque de
déployer puis détruire automatiquement cette application sur AWS en quelques secondes. Le projet Speedlight a été divisé en trois parties
distinctes incluant également la création d'un script python qui modifie la valeur d'un fichier html récupéré via un output terraform.
Partie 1 - AWS Lambda + DynamoDB
Cette partie s'est déroulée sans difficultés majeures. Les
blocs Terraform ont été structurés de la manière suivante : création de la
fonction Lambda, importation du code Python au format zip et définition du
rôle IAM pour la Lambda.
Partie 2 - Importation des fichiers HTML/CSS sur S3
Cette partie a été plus complexe, les étapes comprenaient :
- La création d'un compartiment S3, la modification des
contrôles d'accès (ACL) pour rendre le compartiment S3 public,
- La définition du
compartiment en tant que site web statique,
- La configuration de la redirection
vers le fichier index.html,
- L'importation des stratégies du compartiment S3 via
un fichier JSON, et enfin, l'importation des fichiers front-end (HTML, CSS,
etc.) dans le compartiment.
Le principal défi rencontré ici a été la gestion de
l'importation des fichiers dans le compartiment S3, réglé via l'utilisation d'une
boucle "for_each", qui n'est pas directement prise en charge dans la
documentation Hashicorp.
De plus, Terraform ne vérifie pas automatiquement le contenu
des fichiers pour détecter s'ils ont été modifiés pour les réimportés. Pour
résoudre ce problème, j'ai inclus l'option "etag = filemd5" dans la
boucle, ce qui a permis de garantir que les fichiers seraient réimportés en cas
de modification.
Cependant, il subsiste un problème lié au format des
fichiers importés dans S3 via Terraform, car les métadonnées telles que
"Content-Type: text/html" ne sont pas automatiquement définies lors de l'importation. Cela entraîne
le téléchargement des fichiers au lieu de les afficher lors de l'accès au site
web.
Une solution consisterait à spécifier le "content_type" pour
chaque fichier lors de l'importation, ce qui implique une complication et
refonte total du block d’import via la boucle "for_each".
Il serait plus judicieux de créer le compartiment S3 via
Terraform, mais d'importer les fichiers manuellement ou autres méthodes, car de
cette façon S3 sait reconnaître automatiquement le "content_type" des
fichiers.
Partie 3 - AWS API Gateway
Cette partie devrait être mise en place comme suit :
- Création d'une API Gateway REST,
- Création de méthodes "OPTION, POST" avec une intégration de type "Lambda Function"en liant notre fonction Lambda précédemment
créée
- Ajout de la gestion des
autorisations CORS
- Déploiement de l'API et génération d'une sortie contenant
le lien de l'API à insérer dans notre fichier index.html
La configuration des méthodes "OPTIONS, POST" ont posées des
problèmes, notamment l'absence de certaines configurations qui normalement, n'ont pas besoin d'être spécifiées lors ce que l’ont crée la
ressource manuellement.
Cela a affecté les étapes telles que "Method
Request", "Integration Request", "Method Response" et surtout "Integration Response" où le besoin d'ajouter d'un modèle de mappage (application/json : "{"statusCode":200}") que j'ai eu du mal à trouver. Mais après de nombreuses heures d'essais, ces
configurations sont maintenant correctement gérées via Terraform.
Points à améliorer sur le code fonctionnel :
Revoir la gestion des métadonnées (content_type) lors de l'importation
des fichiers dans S3 via Terraform pour éviter le téléchargement manuel des fichiers sur S3.
Août, 2024 – Aujourd'hui
- Ce poste élargit mes responsabilités (cf. poste précédent) tout en
conservant la gestion du Pôle scientifique.
- Supervision opérationnelle d'une équipe IT pluridisciplinaire (système,
infrastructure, réseau) et appui à la coordination des projets transverses
- Réduction des coûts matériels et maximisation de l’utilisation grâce à la mise en œuvre d’une stratégie de mutualisation GPU via Onyxia (Kubernetes).
- Réduction des dépenses logicielles et augmentation de l’adoption via le déploiement de services cloud open source (Nextcloud, LimeSurvey,
Overleaf, Wordpress, etc...) via Kubernetes.
- Renforcement de la collaboration et du pilotage des projets en tant
qu’interface entre la direction, la DSI, les équipes de recherche et les
prestataires externes.
- Pérennisation de la plateforme Onyxia grâce au pilotage d’un plan de
continuité et de développement (vision, gouvernance, feuille de route).
- Intégration de LLMs on-premise (Ollama/Kubernetes) afin de fournir des
capacités d’IA sécurisées, conformes et maîtrisées au sein du GENES.
Janvier, 2024 – Août, 2024
- Accélération des projets de recherche internationaux grâce à la gestion d’un cluster Kubernetes fournissant du calcul à la demande pour les chercheurs.
- Amélioration de la disponibilité et de la scalabilité par le déploiement et l’intégration de nouveaux services Kubernetes.
- Amélioration de l’efficacité et de la satisfaction des chercheurs via l’analyse de leurs besoins en logiciels, technologies et infrastructures data.
- Standardisation des pratiques et réduction de la charge opérationnelle grâce à la refonte des processus du Pôle scientifique (audit, documentation, workflows, gestion logicielle, cluster Kubernetes).
- Extension stratégique d’Onyxia, plateforme cloud on-premise basée sur Kubernetes pour le calcul, la data science et l’IA, l’établissant comme
solution de référence pour les équipes scientifiques et administratives du GENES.
- Promotion des bonnes pratiques Dev/Data/MLOps en accompagnant les chercheurs dans l’utilisation efficace des services disponibles.
Octobre, 2017 – Novembre, 2018
- Infogérance d'infrastructures pour de multiples clients
- Renouvellement des infrastructures informatiques de nos clients
- Déploiement de solutions IPBX 3CX
- Migration de boites aux lettres vers solution Office 365
- Gestion des ressources et planification de projets
- Monter en compétences des membres de l’équipe
- Travail en équipes interdisciplinaires pour atteindre les objectifs de projets
- Collecte des exigences
Octobre, 2016 – Août, 2017
- Conception, mise en place et administration d’infrastructure de développement (infrastructure linux sur AWS)
- Gestion de la messagerie Office365 et des accès VPN/SSH Pfsense
- Administration et supervision du SI Memority (Infrastructure Linux sur AWS)
- Automatisation de déploiement (python/shell/puppet/ansible/docker)
- Rédaction et amélioration continue de procédure (confluence/jira)
Septembre 2015 – Octobre, 2016
- Gestion et résolution des incidents Niveau I et II
- Gestion du parc informatique, matériels, logiciels et mobile
- Gestion des partages et des droits d’accès
- Assistance aux utilisateurs
- Membre d’un comité de pilotage numérique
- Suivi et gestion des stocks