Forward Deployed Engineer

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 l'administratif. Voilà la matière : l'administratif. Les formulaires, les validations, les rapprochements, les passations de onze jours, le tableur que quelqu'un refait chaque mois. Nous travaillons en deux moitiés. L'une — celle-ci — entre dans une entreprise, découvre ce qui s'y passe réellement, et construit quelque chose assez vite pour prouver si cela vaut la peine d'exister. L'autre reprend ce que nous avons prouvé et en fait quelque chose dont l'entreprise dépend.

La plupart des équipes d'automatisation n'ont que la première moitié, et se retrouvent donc avec un tiroir plein de démos. La plupart des autres n'ont que la seconde, et construisent donc ce que quelqu'un a pensé à demander. Nous recrutons les personnes de la première moitié.

Nous ne cherchons pas seulement un développeur. Nous cherchons quelqu'un doté d'instincts de consultant et qui sait construire — quelqu'un que pourquoi la facture met onze jours intéresse davantage que le framework que nous utilisons, et qui peut ensuite aller construire ce qui répare cela.

En quoi consiste vraiment le poste

Un projet arrive. C'est en général une phrase : « nos équipes passent deux jours par mois à rapprocher cela à la main ». À partir de là, il est à vous.

• Vous y allez. En personne, dans le pays concerné, et vous vous asseyez avec les gens qui font réellement le travail. Pas la description qu'en fait le manager — le travail.
• Vous comprenez le processus pour de bon. Comment il se déroule réellement, qui y touche, où ça fait mal, et ce qu'il coûte aujourd'hui. C'est presque toujours du travail administratif — c'est là que part le temps dans une société de services professionnels, et c'est là que nous gagnons. La durée est fixée par le processus, pas par un calendrier. Quelque chose de simple, c'est quelques jours. Quelque chose de vraiment complexe, c'est des semaines avant que rien ne soit construit, et le dire fait partie du poste : nous préférons de loin entendre « c'est plus emmêlé que ça n'en avait l'air » en semaine une plutôt qu'en semaine six.
• Vous vérifiez ce que nous avons déjà — avant de construire quoi que ce soit. C'est une vraie étape, pas une politesse. Nous détenons un portefeuille, et une part sérieuse de bien faire ce métier consiste à le connaître assez pour que, lorsqu'une entreprise décrit son problème, vous sachiez déjà que nous en avons l'essentiel. Parfois la réponse est nous avons cela, il suffit de le configurer. Plus souvent c'est l'essentiel existe là-bas — et vous prenez ce code pour tailler une PoC dans exactement la partie dont vous avez besoin. Et pas de mémoire seule : vous disposez d'une intelligence de code sur tout le parc, branchée sur un agent à qui vous pouvez donner une spécification et demander qu'est-ce qui, chez nous, fait déjà cela ?
• Vous écrivez l'architecture fonctionnelle. Comment la chose marche — le flux, les acteurs, les règles, les données qui circulent et les décisions au milieu. Le fonctionnel d'abord : c'est un métier de processus métier, pas de conception de systèmes. Vous prendrez des décisions techniques et vous devez pouvoir les prendre, mais l'architecture technique profonde n'est pas votre raison d'être, et les parties qui en demandent une vont au Tech Lab. Ce document est ce à partir de quoi les agents construisent, ce qui fait de son écriture précise l'heure la plus rentable de votre semaine.
• Vous le construisez. Développement agentique, dirigé par vous : de l'idée à quelque chose de montrable en une à deux semaines, une fois le processus compris.
• Vous le mettez devant les gens, encore et encore. Une courte série de prototypes de plus en plus réels, chacun montré aux parties prenantes, chacun meilleur grâce à ce qui est revenu. Cette boucle est à vous, ainsi que les premiers tests.
• Vous dites si cela en vaut la peine. Vous chiffrez le bénéfice depuis le premier jour, donc quand la réponse est non, vous pouvez le dire avec des chiffres.
• Vous l'emmenez jusqu'au MVP, et vous obtenez que les gens s'en servent vraiment. Former les utilisateurs et assurer le suivi ensuite, c'est à vous, pas la réflexion après coup de quelqu'un d'autre.
• Vous écrivez le dossier de transmission pendant que vous construisez, vous remettez l'ensemble à un Product Owner et à un ingénieur, et vous passez au suivant.

Puis vous recommencez, ailleurs, sur quelque chose de complètement différent.

La ligne où vous vous arrêtez — et pourquoi elle vous avantage

Vous menez un projet jusqu'au MVP. Pas jusqu'à la production, et pas pendant des années. Une fois prouvé et presque prêt, notre Tech Lab prend le relais : durcissement, montée en charge, sécurité, le long terme. Vous sortez — vraiment, pas « disponible pour les questions ».

Cette ligne est délibérée et c'est ce que ce poste a de meilleur. Vous n'accumulez jamais de traîne. Vous n'êtes pas la personne que l'on rappelle quatorze mois plus tard pour une chose construite en une après-midi, vous ne maintenez pas six prototypes à moitié vôtres en essayant d'en démarrer un septième, et vous ne devenez pas peu à peu le support de votre propre catalogue. C'est ainsi que ce poste épuise les gens partout où il existe, et c'est l'échec précis contre lequel nous avons monté une deuxième équipe.

Il vous arrivera de rester un peu plus longtemps, et ce sera parce que c'est plus rapide. Si le suivi après lancement se passe bien et que le Product Owner n'est pas encore libre, vous pourrez continuer à le mener un temps plutôt que de laisser la chose perdre son élan — un choix que nous faisons délibérément, à découvert, et toujours avec un ingénieur déjà de l'autre côté. Ce que nous ne faisons pas, c'est vous laisser le porter en silence.

Ce que vous obtenez à la place, c'est la partie que la plupart des ingénieurs disent vouloir et obtiennent rarement : un nouveau problème, une nouvelle entreprise et une page blanche toutes les quelques semaines, avec quelqu'un de compétent à qui remettre le travail terminé.

Un « non » honnête est ici un vrai résultat

Une partie de ce que vous examinerez ne vaudra pas la peine d'être automatisé. Quand c'est le cas, vous arrêtez, vous écrivez pourquoi, et cela compte comme un résultat livré — parce que la personne suivante ne refait pas le travail, et que l'entreprise obtient une réponse au lieu d'un projet.

Cela ne marche que si quelqu'un chiffre le bénéfice depuis la première conversation, et ce quelqu'un, c'est vous. C'est aussi pourquoi nous le pensons vraiment : vous aurez la légitimité de tuer votre propre projet, ce que peu d'entreprises peuvent écrire honnêtement.

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

C'est la partie que nous soulignerions. Nous sommes une équipe native à l'IA, vraiment — pas une équipe qui a ajouté une licence Copilot. Chacun a son propre abonnement Claude Max et un orchestrateur de bureau qui fait tourner plusieurs agents de code en parallèle. Vous apprendrez à piloter cela correctement : comment obtenir vitesse et qualité en même temps, où cela échoue, et comment regarder ce qui est sorti et savoir si c'est réellement juste.

Ce qui change ce que le travail donne au quotidien. Très peu de votre semaine consiste à taper de l'implémentation. L'essentiel porte sur ce qui décide si un logiciel est bon — ce qui devrait exister, quelle forme cela doit prendre, ce que le métier adoptera réellement — puis à descendre dans le détail exactement là où le détail compte. Vous n'avez pas besoin de savoir écrire à la main du code de production ; vous avez besoin de savoir spécifier précisément, diriger correctement et juger ce qui revient. Nous vous formerons à notre architecture, à nos motifs et à notre chaîne. Cette partie est pour nous.

« Si ce sont les agents qui construisent, à quoi je sers ? »

C'est une question juste face à une annonce comme celle-ci, alors voici la réponse honnête : les agents sont la partie la plus rapide de l'équipe et la moins fiable, et nous ne comptons pas là-dessus pour changer. Tout ce qui décide si le projet en valait la peine passe par une personne.

Ce qui reste à vous, définitivement :

• Découvrir ce qui se passe réellement. Personne ne l'a écrit. La personne qui fait le travail décrira la version de la procédure, pas celle avec les trois contournements dedans — et les contournements sont le projet. Repérer cet écart demande un humain dans une pièce.
• Décider ce qu'il ne faut pas construire. La moitié de bien faire ce métier, c'est la réutilisation, le périmètre et le refus. Un agent construira volontiers ce dont personne n'avait besoin.
• Chiffrer le bénéfice, et accepter de dire non. Des chiffres, et le cran de les poser devant la personne qui a demandé le projet.
• En faire une spécification assez précise pour être construite. Un agent construira exactement ce que vous avez spécifié, magnifiquement, même quand ce que vous avez spécifié avait la mauvaise forme. Passer de « ils ont besoin de ça » à une spécification qui produit la bonne chose est l'heure la plus difficile de votre semaine et la seule que rien n'automatise.
• Tout ce qui est humain. Être digne de confiance pour des gens qui n'ont pas demandé votre venue. Dire à une partie prenante que son idée préférée n'en vaut pas la peine. Transmettre si bien que ceux qui héritent n'ont plus besoin de vous.

Notre position, clairement : nous sommes natifs à l'IA parce que cela permet à une petite équipe de faire bien plus que sa taille ne le laisserait croire, pas parce que nous pensons que les personnes sont la partie superflue. Nous recrutons moins de gens, meilleurs, et nous donnons à chacun beaucoup plus de levier — l'inverse de recruter moins parce qu'on en a moins besoin.

Comment nous construisons

Chaque projet part du même squelette, et c'est le même dans la plupart de nos dépôts — délibérément. Pour vous, c'est tout l'intérêt : vous démarrez quelque chose de nouveau toutes les quelques semaines, et aucune de ces semaines ne devrait partir à redécider les cinq mêmes questions. Cela signifie aussi que l'équipe à qui vous transmettez peut reprendre votre projet sans couche de traduction, et que le code trouvé dans l'un de nos produits peut être taillé en prototype pour un autre.

Vous n'avez pas besoin d'arriver en connaissant nos outils. Vous avez besoin d'être assez à l'aise sur le front et le back d'une application web pour diriger un développement et savoir quand quelque chose cloche. Le reste — notre architecture, nos motifs, notre chaîne — c'est ce sur quoi nous vous formons, et c'est une grande partie de ce à quoi sert le certificat.

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

• Vous voyagerez beaucoup, et nous le disons franchement. Barcelone est votre base et le lieu de l'équipe, mais les entreprises sont réparties dans une quinzaine de pays et c'est vous qui allez à elles. Parfois quelques jours. Parfois quelques semaines au même endroit, parce qu'un processus que vous ne pouvez pas voir est un processus que vous comprendrez de travers. Être dans la pièce est la méthode ici — ce n'est pas un supplément occasionnel à un poste de bureau, et si ce n'est pas la vie que vous voulez, ce n'est pas le bon poste et nous préférons tous les deux le savoir maintenant.
• Les déplacements et le logement sont à notre charge, et nous tenons à la différence entre un lit et un endroit où l'on peut réellement vivre quand le séjour est long. Posez-nous la question : nous préférons parler de la façon dont nous gérons un déploiement de trois semaines plutôt que vous le laissiez découvrir.
• Vous n'êtes pas un consultant qui vend des jours. Personne ne compte vos heures. Ce que l'on regarde, c'est si la chose a marché, si elle a été utilisée, et si la transmission a tenu.

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 :

• 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.
• Personne n'est d'astreinte. Jamais. Pas de rotation, pas de bip, pas de numéro de téléphone. Les alertes se déposent dans un canal et attendent.

Et les déplacements se lisent différemment selon l'endroit où l'on se tient. Tout ce qui précède est vrai et nous ne l'adoucissons pas : cela fait beaucoup de temps loin de chez soi. Mais si une part de ce qui vous fait continuer à lire est que vous préféreriez travailler à travers l'Europe plutôt que la lire : ce poste vous emmène dans quinze pays, paie tout, et vous donne un endroit où revenir.

Ce que nous cherchons

Un critère prime sur tout le reste de cette liste, alors le voici clairement. Nous n'exigeons pas que vous soyez le développeur expert — pour le code, vous avez des agents d'IA. Nous exigeons en revanche que vous sachiez architecturer le projet : comprendre le besoin, être réellement à jour sur ce que la technologie sait faire, connaître l'infrastructure sur laquelle vous construisez — puis l'implémenter et le porter de zéro au MVP, où vous le remettez à un Product Owner et à un ingénieur. Si vous lisez cela en vous disant c'est le poste que je veux, continuez.

Lisez le reste comme la description de la personne 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 l'instinct et former le reste — c'est une grande partie de ce à quoi sert le certificat. Si plusieurs de ces points sont vrais de vous et que les autres ressemblent à des choses que vous voulez apprendre, postulez.

• Vous vous intéressez à la façon dont les entreprises fonctionnent réellement. Les processus, le désordre à l'intérieur, et pourquoi les gens font la chose bizarre qu'ils font. Celui-là ne s'apprend pas et tout le reste ici s'apprend.
• Vous savez construire. À l'aise sur le front et le back d'une application web. Le langage que vous utilisiez compte bien moins pour nous que votre capacité à aller d'une idée à quelque chose qui marche, seul.
• Vous cherchez ce qui existe déjà avant d'écrire quoi que ce soit. Les ingénieurs dont nous ne voulons pas sont ceux pour qui chaque problème est un nouveau dépôt. Le nôtre est un métier de portefeuille : savoir ce que nous avons, et être content plutôt que déçu quand la réponse est nous avons déjà construit l'essentiel.
• Vous utilisez sérieusement des agents de code, et vous lisez ce qu'ils produisent comme vous liriez le travail d'un collègue.
• Vous savez entrer dans une pièce pleine de gens qui n'ont pas demandé votre présence et en ressortir avec la vérité. Poser la question qui obtient la vraie réponse, c'est l'essentiel de la première étape.
• Vous écrivez bien. L'architecture, le compte rendu quand la réponse est non, et le dossier de transmission sont tous des documents, et tous les trois sont lus par des gens qui n'étaient pas dans la pièce.
• Vous savez lâcher. Une fois transmis, ce n'est plus à vous. Certaines très bonnes personnes trouvent cela réellement difficile, et il vaut mieux le savoir de soi avant de postuler.
• 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, avec des déplacements.

Ce que vous avez étudié nous est égal. Ce qui compte, c'est ce que vous avez construit, ce que vous avez compris du métier pour lequel vous l'avez construit, 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 un processus métier qu'il vous a fallu comprendre avant de pouvoir le réparer.