Senior DevOps Engineer

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 AI 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 société nouvelle, 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 DevOps, 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, relisibles. 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, 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.
• 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 produits que nous détenons, sans exception.

Nous vous le disons d'emblée parce que ce n'est pas un avantage auquel nous espérons discrètement que vous renoncerez. Beaucoup d'annonces disent « culture d'astreinte saine » et veulent dire une rotation. Nous voulons dire qu'il n'y a pas de rotation.

Voici l'autre moitié honnête, et c'est le poste réel : nous ne pouvons faire cette promesse que parce que nous nous protégeons par l'ingénierie plutôt que par les soirées des gens — et cette ingénierie, c'est ce pour quoi nous vous recrutons. De l'infrastructure as code, pour qu'une machine perdue soit reconstruite plutôt que ressuscitée. Des sauvegardes avec une restauration que nous avons réellement testée. Un retour arrière en un clic que tout le monde a déjà répété. Des alertes qui font la queue au lieu d'appeler, parce que rien à l'autre bout n'est censé répondre la nuit.

L'échange est donc explicite : on ne vous réveille jamais, et en contrepartie les systèmes doivent être réellement récupérables. Si vous avez passé une carrière à être appelé pour des choses qui auraient dû être réglées par l'ingénierie, voici la version du poste où vous faites l'ingénierie.

Pendant les heures de bureau, c'est l'inverse du désengagement. Le PO, les développeurs et l'ingénieur DevOps affectés à un produit portent les incidents de ce produit — le support n'est pas expédié à une équipe séparée, il fait partie de la prise en charge, et c'est ce qui garde tout le monde honnête sur la qualité.

Comment nous construisons — délibérément ennuyeux, et vous avez voix au chapitre

Nous avons une stack posée et c'est la même dans la plupart des dépôts exprès : un squelette, des paquets partagés, push pour déployer. Le gain, c'est qu'une équipe de deux peut reprendre un produit jamais vu et être utile le jour même, ce qui est la seule raison pour laquelle une équipe de cette taille peut porter autant de produits.

Nous construisons la plateforme la plus simple qui satisfasse l'exigence, et nous sommes stricts sur ce qu'est réellement l'exigence. Ici, la complexité doit gagner sa place : chaque capacité que nous exploitons est une chose de plus qu'une seule équipe doit comprendre, corriger et savoir reconstruire.

Un exemple concret, parce qu'il en dit long sur nous : nous ne faisons pas tourner Kubernetes, et c'était une décision et non un oubli. Nous l'avons examiné sérieusement, deux fois — la dernière parce que nous craignions de nous être trompés — et les deux fois la réponse a été qu'un petit portefeuille sur un trafic prévisible n'a pas assez besoin d'ordonnancement multi-nœuds et d'autoscaling pour les payer avec le seul ingénieur d'infrastructure dont nous disposons. Nous avons écrit les conditions précises dans lesquelles nous changerions d'avis, et le jour où l'une d'elles est remplie, nous changerons.

C'est bien pourquoi nous demandons quelqu'un qui a fait tourner Kubernetes en production et qui sait nous dire quand ce n'est pas la réponse. Si votre idée d'une bonne semaine est de régler un cluster, ce n'est pas le bon poste et nous préférons que vous le sachiez maintenant. Si votre idée d'une bonne plateforme est celle qu'une petite équipe peut comprendre entièrement, reconstruire depuis un dépôt et transmettre à un nouvel arrivant en une après-midi — et que vous avez assez de cicatrices pour savoir où cela cesse de suffire — ce jugement est l'essentiel de ce que nous recrutons.

C'est un défaut, pas une camisole. Certaines choses ont réellement besoin d'autre chose, et dans ce cas nous nous adaptons délibérément, avec le raisonnement écrit. Ce que nous ne faisons pas, c'est redécider les cinq mêmes questions sur chaque nouveau dépôt par habitude.

Et vous avez voix au chapitre sur ce qu'est le standard. N'importe qui peut proposer un changement — quelque chose de neuf réellement meilleur, quelque chose vers quoi nous devrions monter, quelque chose que nous avons raté. Une proposition est instruite sérieusement face aux alternatives, elle obtient une réponse, et si la réponse est non vous obtenez le raisonnement. Sur l'infrastructure, vous n'êtes pas une voix parmi d'autres — vous êtes celui qui décide, dans un budget que vous aidez à fixer.

Vous allez devenir très bon en construction avec des agents d'IA

Nous sommes une équipe d'ingénierie native à l'IA, vraiment — pas une équipe qui a ajouté une licence Copilot. Chaque ingénieur a son propre abonnement Claude Max et un orchestrateur de bureau qui fait tourner plusieurs agents de code en parallèle, chacun sur sa branche. Cela vaut pour vous aussi : une grande partie du travail d'infrastructure se spécifie désormais plus qu'elle ne se tape, et vous deviendrez très bon à piloter cela — là où ça marche, là où ça échoue, et comment lire un diff et décider si c'est réellement juste.

Cela rend aussi votre poste plus intéressant que le même intitulé ailleurs, parce que l'ingénierie agentique crée des problèmes d'infrastructure que la plupart des équipes n'ont pas encore :

• Les agents installent des paquets dans du code voisin de données clients. L'hygiène de la chaîne d'approvisionnement cesse d'être une case de conformité et devient un contrôle vivant dont vous répondez.
• Les agents détiennent des identifiants — ou plutôt, ils ne le doivent pas. Intermédier l'identité machine pour que l'agent ne touche jamais la vraie clé est un problème de conception, et il est à vous.
• Les agents coûtent de l'argent d'une manière invisible jusqu'à la facture. Budgets par projet, plafonds durs, et une alerte qui se déclenche avant le plafond, pas après.
• Les agents peuvent déployer. Ce qui veut dire que les garde-fous entre « un agent a proposé cela » et « cela est en production » relèvent de l'infrastructure, pas de la politique interne.

Si vous faites tourner des agents sérieusement et que vous avez des avis sur là où ils cassent, nous voulons les entendre. Si vous êtes curieux sans être encore dedans, c'est très bien : bien enseigner cela est une chose pour laquelle nous comptons être connus.

Ce qu'il vaut mieux savoir d'emblée

• C'est un poste sur site à Barcelone. Plus que les autres postes ici, et pour une vraie raison : vous montez de l'infrastructure et des accès quasi physiques pour une équipe que l'on assemble autour de vous, dans sa première année, et l'essentiel de cela va plus vite dans une pièce.
• Vous êtes le seul ingénieur DevOps pour un temps. C'est de l'autorité, et c'est aussi un facteur bus — d'où le fait que « rien n'existe uniquement dans la tête d'une personne » soit inscrit dans le poste plutôt qu'espéré. Tout ce que vous construisez est documenté et reproductible au fil de l'eau, pas après.

Si vous déménagiez à Barcelone pour ce poste

Nous n'attendons pas de vous que vous absorbiez le coût du déménagement, et nous préférons dire ce que nous prenons en charge plutôt que vous laisser demander.

• Nous payons pour vous faire venir. Les vols, le logement du premier mois le temps de trouver le vôtre, les frais de visa et de dossier, et un intermédiaire qui s'occupe de la bureaucratie — le NIE, le rendez-vous TIE, les apostilles — plutôt que de vous laisser affronter seul l'administration espagnole. Des cours d'espagnol si vous les voulez.
• Une prime de relocalisation, versée à l'arrivée plutôt qu'au goutte-à-goutte. Elle n'est remboursable que si vous partez dans les dix-huit premiers mois, et c'est cette condition qui nous permet de la verser d'avance : changer de pays coûte de l'argent au début, pas en deuxième année.

Trois choses valent ici plus qu'il n'y paraît dans une comparaison d'offres, en particulier face à une offre américaine :

• Personne n'est d'astreinte. Jamais. Cela a sa propre section plus haut et nous le pensons littéralement. Si vous venez d'un marché où le travail d'infrastructure et un bip sont supposés aller ensemble, relisez cette section deux fois — c'est la plus grande différence entre ce poste et le même intitulé ailleurs, et ce n'est pas un avantage auquel nous espérons discrètement que vous renoncerez.
• Une couverture santé sans prime, sans franchise et sans réseau imposé — dès le premier jour, et sans être liée au fait de rester à ce poste.
• Trente jours calendaires de congés — soit 22 jours ouvrés — plus quatorze jours fériés, environ sept semaines au total. C'est le plancher légal en Espagne, pas un avantage dont nous nous montrerions généreux.

Et la ligne « sur site » se lit différemment selon l'endroit où l'on se tient. Pour quelqu'un déjà à Barcelone, c'est une contrainte et nous avons dit pourquoi. Pour quelqu'un qui s'y installe, c'est presque tout l'intérêt : c'est un poste à Barcelone, pas un poste que l'on fait depuis Barcelone — une équipe qui s'assoit ensemble, dans une ville où il vaut la peine d'être physiquement présent.

Ce que nous cherchons

Lisez ceci comme la description de l'ingénieur que vous serez ici, pas comme une liste avec laquelle il faut arriver. Presque personne ne coche tout le premier jour, et nous préférons recruter quelqu'un qui a l'instinct et former le reste — c'est une grande partie de ce à quoi sert le certificat.

• Vous avez déjà construit de l'infrastructure à partir de rien, et elle a survécu à l'usage des autres. Une plateforme qu'on vous a confiée et que vous avez maintenue convient ; une plateforme que vous avez créée est ce que nous demandons. C'est le seul point non négociable, et c'est pourquoi le poste est senior : il n'y a personne ici pour relire votre travail, et la plateforme que vous posez est celle sur laquelle tous les autres construisent pendant des années.
• L'infrastructure as code est votre façon de travailler, pas un outil que vous avez utilisé. Vous savez dire ce que vous faites quand la réalité et le dépôt divergent, parce qu'ils finissent toujours par diverger.
• Vous avez porté des sauvegardes et vous en avez réellement restauré — sous pression, idéalement quand cela comptait. Tout le monde a des sauvegardes. Bien moins ont restauré.
• Vous êtes à l'aise pour faire tourner des choses sur vos propres serveurs, pas seulement sur une console de cloud managé. Nous détenons notre infrastructure délibérément, et c'est une compétence différente de la configuration de celle d'un autre.
• Vous avez fait tourner Kubernetes en production — et vous êtes tout aussi à l'aise pour dire quand ce n'est pas la bonne réponse. Nous ne le faisons pas tourner aujourd'hui. Si et quand nous le ferons est l'une des décisions que porte ce poste, et nous préférons qu'elle soit prise par quelqu'un qui a vécu avec la chose plutôt que par quelqu'un qui raisonne de l'extérieur.
• Vous vous automatisez hors de la boucle, et vous écrivez les choses. La mesure de ce poste, c'est le peu qui en dépend de vous en particulier.
• Vous savez dire non à la complexité. Le meilleur ingénieur pour ce poste est celui qui construit la chose ennuyeuse qui marche et résiste à la chose intéressante qui n'a pas besoin d'exister.
• La sécurité est un instinct, pas une étape. Secrets, accès, moindre privilège, correctifs — les disciplines ennuyeuses, tenues avec constance.
• Anglais courant. C'est notre langue de travail — nous travaillons dans une quinzaine de pays. L'espagnol est réellement utile au quotidien. Le catalan n'est pas requis.
• Barcelone. C'est une équipe qui s'assoit ensemble, surtout la première année.

Ce que vous avez étudié nous est égal. Ce qui compte, c'est ce que vous avez construit et exploité, et si vous savez nous détailler les décisions qu'il contient.

Comment nous recrutons — les deux tours bâtis pour ce poste

1. Un échange de trente minutes. Ce que vous avez construit, comment vous travaillez, et comment vous y réfléchissez. Nous vous demanderons de nous détailler quelque chose que vous avez construit, puis de justifier une décision précise à l'intérieur. Cela ne se prépare pas et ne cherche pas à vous piéger ; c'est ainsi que nous distinguons la compréhension de la familiarité.
2. Un projet. Nous vous donnons un brief et un environnement de travail pour le construire, avec Claude Code déjà installé et relié à une clé, pour que vous construisiez comme nous construisons réellement plutôt que d'en parler devant un tableau. C'est du vrai travail et non une énigme, vous le faites à votre rythme — pas de semaine à poser, pas de vols, rien qui exige d'être déjà disponible — et nous reprenons ensemble ensuite ce que vous avez construit.

Mainloop · Barcelone. Postulez avec quelque chose que vous avez construit et un paragraphe sur une panne que vous avez causée ou héritée, et ce que vous avez changé ensuite.