Le fil conducteur de mon parcours est une question : comment construire des systèmes sur lesquels on peut compter, et prendre des décisions que l’on peut expliquer ? Elle relie mes domaines techniques au rôle de Technical Project Leader.
Cette page présente une démarche professionnelle, plutôt qu’une chronologie d’employeurs ou de missions. Elle explique la continuité entre infrastructure, automatisation, fiabilité et pilotage.
Partir de ce qui se passe réellement
Un schéma d’architecture offre une représentation du système. La production montre ses interactions : dépendances, délais, erreurs, opérations de maintenance. Je m’intéresse à ce passage du modèle au fonctionnement réel. Ce qui mérite d’être documenté n’est pas seulement la configuration nominale, mais aussi la façon de reconnaître et de traiter les écarts.
Cette attention conduit naturellement à la fiabilité : choisir ce que l’on mesure, comprendre les attentes et rendre un diagnostic partageable. L’article SRE et systèmes critiques développe ces questions de manière pratique.
Faire de l’automatisation un objet d’ingénierie
Automatiser permet de rendre une opération reproductible. Cela oblige aussi à formuler ce qui était implicite : préconditions, permissions, erreurs possibles et critères de réussite. C’est cette précision qui m’intéresse dans Python, Ansible et l’Infrastructure as Code.
Le problème ne se termine pas quand un programme s’exécute. Il faut savoir ce qu’il a changé et ce qu’il doit faire lorsqu’il ne peut pas terminer. J’explore ce sujet dans automatiser sans perdre le contrôle.
Étendre la fiabilité à la confiance
La continuité d’un service dépend également de ses identités et de ses certificats. Un certificat renouvelé mais non déployé, ou une permission qui survit à son usage, montrent combien sécurité et exploitation sont liées.
Mon positionnement autour du Digital Trust part de cette relation. Il ne s’agit pas d’ajouter une promesse abstraite de confiance, mais de comprendre les mécanismes qui permettent de la vérifier et de la retirer.
Relier la décision technique au projet
Le pilotage technique demande de faire travailler ensemble des contraintes différentes : disponibilité, sécurité, délais, dépendances et capacité des équipes. Ma démarche consiste à rendre les arbitrages visibles, à découper les changements et à définir les preuves qui autorisent la suite.
Une décision bien documentée doit rester compréhensible après la réunion. Un projet livré doit rester exploitable après son lancement. Ces deux exigences structurent le dossier Technical Project Leadership.
Documenter cette démarche
Ce site en est un prolongement : des projets identifiables, des analyses techniques sourcées, et une séparation claire entre faits, exemples et propositions de méthode. La présentation de mon expertise complète ce récit avec les domaines techniques concernés.