Construisez toute la plateforme de livraison d'une société depuis le premier commit, avec la sécurité dedans dès ce même commit, prenez-la entièrement en charge, et ne portez jamais de bip. Les deux moitiés de cette phrase sont délibérées. L'infrastructure as code, à partir de zéro La CI/CD et le chemin de mise en production La sécurité dans le pipeline, et les secrets — y compris pour les agents L'observabilité, les sauvegardes et une restauration testée C'est un poste senior et ce n'est pas un poste que nous pouvons pourvoir en junior — vous êtes le premier, pour un temps le seul, et la plateforme sur laquelle tous les autres construisent est celle que vous posez. Mainloop est une société d'ingénierie à Barcelone. Nous détenons ce que nous construisons et nous ne rendons de comptes qu'à nous-mêmes. Vous avez la partie intéressante d'une jeune société, avec un vrai client et de vrais produits dès le premier jour. Ce que nous construisons, c'est le logiciel qui automatise le travail des services professionnels — dans une quinzaine de pays, pour des entreprises qui se noient dans les processus. Nous construisons ces produits et nous les exploitons. Cette seconde moitié est la raison d'être de ce poste, et ce n'est pas une formalité : une équipe qui décide comment son logiciel est construit devrait décider comment il est livré. Vous êtes la personne qui met fin à cela. Vous êtes notre premier ingénieur DevSecOps, et pour un temps le seul. En quoi consiste vraiment le poste Vous n'héritez pas d'une plateforme. Vous l'écrivez. Il n'y a aujourd'hui aucune infrastructure as code dans notre parc — pas une ligne. Votre premier travail est de rendre cela définitivement faux : tous les environnements que nous exploitons reproductibles depuis un dépôt versionné, dès votre première semaine, avant que l'habitude ne s'installe.



Dans vos premiers mois, vous allez : Construire la plateforme depuis du code. Machines, réseau, ingress, accès, environnements — versionnés, paramétrés, soumis à relecture. C'est le moment le moins coûteux où cela sera jamais fait, et vous le faites correctement au lieu de le rattraper après coup. Rendre le déploiement autonome. Aujourd'hui, livrer une application existante est un git push ; monter une nouvelle demande des droits d'administration et deux pièges non documentés. Combler cet écart est à vous : un chemin balisé, jusqu'à une seule commande, pour qu'un développeur ne tienne jamais un identifiant de plateforme. Gérer les secrets correctement. Un vrai gestionnaire de secrets machine et — parce que nous faisons tourner beaucoup d'agents d'IA — des identifiants intermédiés de sorte qu'un processus agent ne détienne jamais qu'un substitut, jamais une clé. Si vous avez des avis sur la façon d'empêcher un agent victime d'une injection de prompt de fuiter un identifiant de production, cette partie vous plaira ; presque personne n'a l'occasion de la concevoir depuis zéro. Mettre la sécurité dans le pipeline, pas après. Analyse statique, scan des dépendances et des images de conteneur, détection de secrets et contrôles de l'infrastructure as code comme portes sur chaque merge ; des scans dynamiques contre les environnements de preview ; et chaque vulnérabilité remontée à un seul endroit où elle est triée,



attribuée et fermée — pas éparpillée sur une douzaine de tableaux de bord que personne n'ouvre. La mesure n'est pas le nombre de scanners qui tournent. C'est le peu de vulnérabilités encore ouvertes un mois plus tard, et la rareté des cas où quelqu'un ressent le besoin de contourner une porte. Prouver la restauration. Nous avons un standard écrit qui dit que quelqu'un le déploie n'est pas quelqu'un a prouvé que la restauration fonctionne. Vous ferez l'exercice et vous écrirez le compte rendu. Construire le chemin de mise en production. Du commit à la production, avec une barrière de tests automatisée, des URL de prévisualisation par branche qu'une partie prenante peut ouvrir depuis son téléphone, et un retour arrière que toute l'équipe a répété avant d'en avoir besoin. Puis faire tourner tout cela — et le rendre toujours plus ennuyeux. Observabilité, plafonds de coûts, hygiène des dépendances, le travail sans gloire qui décide si une petite équipe peut porter beaucoup de produits. Et vous aurez l'autorité qui va avec. Vous n'implémentez pas la conception de plateforme de quelqu'un d'autre. Comment cela se construit, c'est vous qui le décidez. Nous recrutons au niveau senior précisément pour que ces décisions puissent être les vôtres — la plateforme sur laquelle tourne ici chaque produit est celle que vous posez, et nous préférons faire entrer le jugement plutôt que le superviser. Personne n'est d'astreinte. Jamais. Pas de rotation, pas de bip, pas de numéro de téléphone, pas de « garde juste un œil dessus ce week-end ». Les alertes se déposent dans un canal d'équipe et y attendent. C'est une décision consignée, pas un oubli que nous redécouvrirons plus tard — et elle s'applique à tous les pr

📌 Senior DevSecOps Engineer (Barcelona)
🏢 Mainloop
📍 Barcelona