De la conception à la mise en ligne, je m’occupe de tout.

Un déploiement fait à la main est un déploiement qu'on redoute, donc qu'on repousse. Il finit par partir un vendredi soir avec trois semaines de changements accumulés, et plus personne ne sait lequel a cassé la production.

Je monte une chaîne où la mise en production redevient un non-événement : un merge, un pipeline vert, c'est en ligne. L'image validée en staging est celle qui part, et le retour arrière est prêt avant qu'on en ait besoin.

Une infra qui rame et qui coûte cher a rarement un seul coupable. Le réflexe consiste à ajouter des machines, ce qui traite le symptôme au prix fort et masque le vrai goulet jusqu'au pic suivant.

Je mesure d'abord sous charge réaliste, puis je ne touche qu'à ce qui pèse vraiment. L'élasticité est ensuite branchée sur la métrique qui décrit la charge, et le dimensionnement redescend sur tout ce qui dormait.

Un système qu'on ne mesure pas est un système dont on apprend la panne par ses utilisateurs. Et quand on finit par poser des sondes dans l'urgence, elles arrivent en ordre dispersé : chaque service son format, chaque équipe son outil, et personne ne sait relier une lenteur perçue à sa cause.

Je pose la chaîne complète, traces, métriques et logs, sur les services qui comptent, derrière un point de collecte unique qui garde les applications indépendantes du stockage. Le travail s'arrête quand un incident se voit sur un écran avant qu'un utilisateur n'écrive.

« Ça marche sur ma machine » est le symptôme d'un environnement que personne n'a écrit. Tant qu'il vit dans la tête d'une personne et dans l'historique d'un serveur, chaque nouvelle machine et chaque nouvel arrivant relancent la même enquête.

Conteneuriser revient à écrire cet environnement une fois pour toutes, orchestrer à décider à l'avance de ce qui se passe quand une instance meurt à trois heures du matin. Je fais les deux, avec la bascule documentée.

Les secrets ne fuient presque jamais par une attaque sophistiquée. Ils fuient par un .env commité, un mot de passe collé dans un canal Slack, un ancien collègue parti depuis six mois qui a toujours ses accès.

Je referme ces chemins un par un. Les secrets sortent du dépôt et des images pour vivre dans un coffre, les services les lisent au démarrage, et révoquer un accès redevient l'affaire d'une minute.

Une application en ligne sans barrière est une base de données publique avec une interface. Et une barrière posée uniquement dans le front donne le même résultat en donnant l'illusion inverse : il suffit d'appeler l'API directement pour passer à côté.

Je pose le contrôle là où il tient, sur le serveur, à chaque requête. Les identifiants passent par le fournisseur d'identité déjà en place, les sessions restent courtes et révocables, et chaque accès sensible laisse une trace.

Une base montée à la va-vite tient jusqu'au jour où il faut la faire évoluer ou la restaurer. Les deux moments arrivent toujours, souvent le même mois, et c'est là qu'on découvre que la sauvegarde nocturne n'a jamais été relue.

Je remets de l'ordre dans le schéma, je rends les évolutions rejouables en versionnant les migrations, et je vérifie la sauvegarde en la restaurant pour de vrai.

Dès que les volumes deviennent réguliers ou que les données sont sensibles, envoyer chaque requête chez un fournisseur externe devient coûteux et discutable. Le prix suit l'usage sans plafond, et les documents partent chez un tiers.

Je fais tourner un modèle ouvert sur une machine maîtrisée, dimensionnée honnêtement pour la charge réelle, derrière une API privée. Les données ne quittent pas le périmètre, l'ensemble est hébergeable en France, et le coût redevient prévisible.

Une fonctionnalité IA se juge sur ce qu'elle produit, pas sur la taille du modèle derrière. Passer systématiquement par le plus gros modèle disponible fait grimper la facture pour une qualité souvent identique, et sans jeu de test personne ne peut dire si un changement améliore quoi que ce soit.

Je découpe le besoin en tâches et j'affecte à chacune le plus petit modèle qui la tient. Les appels restent serverless tant que le volume ne justifie pas d'infrastructure, les dépenses sont plafonnées, et chaque changement se mesure sur des cas réels.

À partir de deux fournisseurs, chaque application se met à porter ses propres clés, son propre format d'appel et sa propre gestion d'erreur. Changer de modèle demande alors un redéploiement, et personne ne sait quelle équipe consomme quoi.

Je ramène tout cela à un point unique. Les applications parlent un seul format, le routage vit dans la configuration, et chaque équipe reçoit sa clé, son quota et sa ligne de coût.

Une donnée confiée à un service américain reste soumise à un droit étranger, même stockée dans une région européenne. Et le sujet n'arrive jamais seul : il y a l'hébergement, mais aussi les sauvegardes, les logs, les outils de suivi et les modèles d'IA, qui partent souvent ailleurs sans que personne l'ait décidé.

Je monte la chaîne complète chez des hébergeurs français, Scaleway, OVH ou IONOS, et je vérifie que rien n'en sort par une porte de service. On sait alors où vit chaque donnée, qui peut y accéder, et on peut le prouver.

Un produit livré sans sa chaîne de déploiement ni sa documentation n'est pas terminé : il est posé sur une machine. La personne qui reprend derrière repart de zéro, et la moindre correction commence par retrouver comment le tout a été mis en ligne.

Je construis le produit et sa chaîne en même temps. Le déploiement, l'observabilité et les sauvegardes existent avant la mise en ligne, et le code reste lisible pour l'équipe qui le reprendra.

Un MVP mal cadré devient un produit complet livré à moitié : trop long à construire pour apprendre vite, trop incomplet pour convaincre. Et sans rien mesurer une fois en ligne, le test ne tranche rien.

Je pars de l'hypothèse à valider et je coupe tout ce qui n'y répond pas. Le reste est écrit mais pas construit, la v1 sort avec sa télémétrie, et le bilan arrive avec des chiffres.

Un tableau de bord n'a de valeur que si quelqu'un change une décision en le regardant. La partie difficile n'est pas de tracer des courbes : c'est que deux services calculent le même indicateur de deux façons, et que personne ne sait laquelle fait foi.

Je fais définir chaque chiffre par ceux qui l'utilisent, puis j'écris cette définition à côté du chiffre. Les vues sont construites par usage, et le rafraîchissement est surveillé pour qu'un dashboard ne mente jamais en silence.

Une facture cloud qui grimpe sans explication est presque toujours une facture qu'on ne sait pas ventiler. Tant que chaque euro n'est pas rattaché à un service, aucune optimisation ne peut être arbitrée et la discussion se termine sur des impressions.

J'étiquette les ressources pour rendre la ventilation possible, puis je remonte le coût dans les mêmes dashboards que la charge. Chaque optimisation devient comparable, et vérifiable sur la facture du mois suivant.