Entrez dans une entreprise qui n'a jamais été automatisée, comprenez comment elle fonctionne réellement, et ayez quelque chose qui marche devant elle en deux semaines. Puis transmettez correctement, et allez le faire ailleurs.
Comprendre le processus, sur placeÉcrire l'architecture fonctionnelleMener le développement agentique jusqu'à la PoCTenir la boucle avec les parties prenantesChiffrer le bénéfice — et dire non quand c'est nonLe dossier de transmissionMainloop 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 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 posteUn 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 poste 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

📌 Forward Deployed Engineer (Barcelona)
🏢 Mainloop
📍 Barcelona