Il y a presque cinq ans, nous avions écrit ce que signifiait être full-stack de bout en bout : concevoir et fabriquer en interne la mécanique, l'électronique, le firmware, le backend, les modèles de ML, les outils ainsi que les applications mobiles et web. Tout cela reste vrai. Mais la stack a évolué, et une chose a changé le quotidien de l'ingénierie ici plus que toute autre depuis : nous concevons désormais nos propres agents d'IA pour aider à construire et à faire tourner Minut.
Voici donc l'édition 2026.
Minut est la couche d'intelligence de la gestion immobilière proactive. Nous aidons les gestionnaires de locations de courte durée, d'apparthôtels, de résidences étudiantes et de logements multifamiliaux à garder une longueur d'avance sur des problèmes comme le bruit, la fumée et les moisissures, grâce à un petit capteur respectueux de la vie privée et à une plateforme qui transforme les données en actions pour améliorer l'expérience des voyageurs et le travail des gestionnaires. Il y a des capteurs Minut dans plus de 100 pays. (Nous attendons d'ailleurs toujours notre première introduction en Antarctique.)
Voici ce que nous utilisons chez Minut en 2026 :
Travailler dans une équipe full-stack de bout en bout, c'est apprendre de personnes aux compétences extrêmement variées. Nous avons toujours des discussions techniques, planifiées comme spontanées, sur l'architecture, l'outillage, l'expérience développeur et, de plus en plus, sur jusqu'où nous pouvons pousser les agents pour qu'ils fassent les tâches ennuyeuses à notre place.
Nous sommes une équipe soudée d'ingénieurs qui travaille étroitement avec les designers, les PM et les parties prenantes. Les ingénieurs sont impliqués tôt dans le cadrage des problèmes, et nous préférons toujours livrer plusieurs fois par jour, automatiquement, une fois la revue de code validée.
.png)
Notre tableau de bord web sur web.minut.com est une application monopage construite avec React 19 et TypeScript, empaquetée avec Vite (nous avons abandonné Gatsby). L'état serveur est géré avec TanStack Query au-dessus de hooks d'API entièrement typés, générés à partir de notre schéma OpenAPI, de sorte qu'un changement dans le contrat backend apparaît comme une erreur de type dans le frontend avant même d'être livré. Nous avons construit notre propre design system, affectueusement surnommé meatball-ui, qui est aujourd'hui le premier réflexe pour construire une interface, stylisé avec styled-components. Les tests tournent sur Vitest ; Prettier, ESLint et une vérification de code mort gardent le tout propre.
L'application web, comme les applications mobiles, communiquent avec la même API HTTP RESTful et versionnée que nos clients Pro et Enterprise utilisent pour leurs intégrations. Le backend est une vaste base de code TypeScript (en mode strict, du début à la fin) qui tourne sur Node.js et Express. L'API est conçue d'abord par le schéma : nous la définissons en TypeSpec, la compilons en OpenAPI, en générons les types, et validons chaque requête à l'exécution. Elle est versionnée de la v1 jusqu'à la v8, soit cinq ans d'évolution du contrat sans casser les clients qui en dépendent. Pas de GraphQL ; juste une API REST dans laquelle nous avons beaucoup investi.
Nos capteurs ne parlent pas HTTP. Ils maintiennent des connexions TCP persistantes chiffrées en TLS, en échangeant des Protocol Buffers. Notre backend tourne donc en réalité comme deux flottes : une plus petite qui sert l'API REST, et une plus grande qui maintient des dizaines de milliers de connexions d'appareils en direct simultanément. Garder autant d'appareils sur batterie connectés, synchronisés et peu coûteux à interroger est l'un des problèmes les plus intéressants sur lesquels nous travaillons.
Derrière les capteurs se trouve une plateforme de données qui a beaucoup mûri. Nous pratiquons la persistance polyglotte : MongoDB comme base de données opérationnelle principale, une couche relationnelle sur AWS RDS, Redis pour le cache et la limitation de débit, OpenSearch pour les journaux des appareils et d'audit, et S3 pour les objets. Les relevés bruts des capteurs, minute par minute, sont énormes ; nous avons donc construit Granite, un moteur de séries temporelles maison qui garde une fenêtre chaude en SQL et déplace tout le reste vers un stockage froid moins coûteux.
Pour l'analytique, nous exploitons un entrepôt PostgreSQL qui réunit au même endroit un clone du backend, le flux d'événements, la facturation et des centaines de tables d'analyse produit, le tout interrogeable.
Nous ne communiquons pas nos chiffres d'échelle, mais suivre le rythme de la croissance est l'un des défis d'ingénierie les plus stimulants sur lesquels nous travaillons en permanence. Un bug livré à la légère atteint un grand nombre de foyers : voilà pourquoi nous prenons les tests et l'observabilité au sérieux (New Relic, Rollbar, Grafana, Prometheus, OpenSearch), et pourquoi notre CI/CD est entièrement automatisé : GitHub Actions, avec des runners auto-hébergés, construit et teste chaque modification, pousse une image vers notre registre Docker, déploie sur Kubernetes, publie le résultat sur Slack et annote Grafana. (Jenkins, notre cheval de bataille de 2021, est désormais en grande partie à la retraite.) Toute notre infrastructure est en Terraform.
Cette partie n'a pas changé, car c'est tout l'intérêt. Le monitoring respectueux de la vie privée est simple en principe et difficile en pratique ; nous avons conçu une nouvelle façon d'identifier des événements précis sur des capteurs alimentés par batterie sans compromettre la vie privée des voyageurs (brevet américain US20200143823A1).
Les données brutes sont traitées directement sur le capteur et ne sont jamais partagées avec Minut ni avec qui que ce soit. Lorsque l'appareil détecte un événement potentiellement critique, par exemple un bris de verre, une hausse brutale de température ou une montée soutenue du niveau sonore, il envoie une empreinte compacte de cet événement dans le cloud, où des modèles plus puissants l'examinent de plus près avant que quoi que ce soit ne parvienne à l'utilisateur. Le capteur n'a pas de caméra et n'enregistre aucun son. Il ne l'a jamais fait, et ne le fera jamais.
Oui, cela signifie toujours faire tourner des modèles de ML entraînés sur un microcontrôleur à 96 MHz avec moins de 256 ko de RAM, sur batterie, jusqu'à un an. Et l'éventail des choses que nous pouvons détecter directement sur l'appareil s'est élargi : la fumée de cigarette, l'estimation de la foule et de l'occupation, le risque de moisissures et les sons d'autres alarmes. En savoir plus sur notre approche de la vie privée.
Détecter un problème, ce n'est que la moitié du travail. L'autre moitié consiste à aider les gestionnaires à réagir sans être d'astreinte à 3 h du matin, et c'est de plus en plus là que l'IA intervient dans le produit.
Nous sommes pragmatiques quant aux modèles que nous utilisons et à leur usage. Nos fonctionnalités d'IA destinées aux clients tournent sur OpenAI (avec OpenRouter comme passerelle secondaire), gérées via un système de prompts versionné et adossé à une base de données, ce qui nous permet d'itérer sur les prompts comme nous itérons sur le code. Voici quelques-unes des choses qu'elles rendent possibles :
L'IA gère l'intégralité de notre pipeline de localisation : les traductions vivent sous forme de YAML dans leur propre dépôt, et chaque push déclenche une GitHub Action qui traduit automatiquement en sept langues (le japonais est la plus récente) et distribue les résultats vers le web, le backend, la boutique en ligne, iOS et Android.
Voici le plus grand changement depuis 2021, et celui qui nous enthousiasme le plus. Si OpenAI fait tourner le produit, Claude Code d'Anthropic fait tourner notre ingénierie, et nous nous y sommes engagés à fond, non pas comme une fenêtre de chat sur le côté, mais comme une véritable infrastructure intégrée à notre façon de travailler.
Chaque pull request est relue par l'IA avant qu'un humain ne la regarde. Un bot exécute plusieurs CLI d'agents de code en parallèle sur des runners auto-hébergés, avec des passes distinctes pour les bugs, la sécurité, les conventions et les exigences, plus une passe de consolidation accompagnée d'un « guide du relecteur » lisible par un humain. Il récupère le ticket Jira pertinent pour le contexte, publie de vrais commentaires en ligne sur les lignes exactes, et une fois qu'un humain a approuvé, il peut approuver en tant que code owner.
Un autre groupe d'agents surveille les livraisons et fait en permanence deux choses : d'abord, mettre à jour la documentation interne et externe pour que notre centre d'aide et notre équipe soient toujours à jour. Ensuite, repérer les bugs et les correctifs courants dont l'IA peut tirer des enseignements pour améliorer les développements futurs.
Créer un nouvel outil interne tient en une seule commande. Notre plateforme d'applications internes (MIAS) provisionne de bout en bout toute une application de production à partir d'une seule commande : dépôt, base de données, authentification, hébergement, DNS, secrets, entrée au registre. Les nouvelles applications sont agent-native dès leur naissance : le scaffolder y dépose le contexte et les compétences dont Claude a besoin, si bien que Claude vous interroge sur ce que vous construisez puis écrit lui-même la première fonctionnalité. Chaque application hérite gratuitement de la connexion partagée, de Slack et de l'e-mail, ainsi que d'un widget de retour qui ouvre un ticket directement auprès du responsable, sans tri humain intermédiaire.
La même philosophie traverse nos opérations. Nous maintenons une bibliothèque partagée de compétences et de sous-agents Claude Code que chaque ingénieur installe en local pour démarrer un ticket, le répartir entre les plateformes, s'auto-relire, déboguer un problème Sentry ou livrer.
Nous avons un workflow qui mène une erreur de production jusqu'à une pull request en brouillon testée, par lui-même, en pilotant une CLI dédiée que nous avons écrite spécialement pour qu'un agent puisse la consommer.
Rien de tout cela ne remplace les ingénieurs. Cela supprime les corvées autour d'eux, comme le boilerplate, la première passe de relecture, le provisionnement, l'archéologie du « pourquoi cette erreur se produit-elle », pour que les décisions intéressantes captent davantage notre attention. Si construire et vivre au sein d'un tel environnement vous semble amusant, vous vous y sentirez parfaitement à votre place.
Les applications mobiles de Minut sont toujours développées nativement, sur iOS comme sur Android. Ce qui a changé, c'est que nous sommes désormais résolument entrés dans l'ère moderne et déclarative : iOS privilégie SwiftUI et Android privilégie Jetpack Compose, sur Kotlin. Les Protocol Buffers restent la colonne vertébrale de la communication entre les deux applications et les appareils, à l'image du firmware.
Nous gardons l'esprit ouvert sur le code partagé et la vitesse de développement, mais pour nous, le natif reste la bonne fondation.
Depuis le début, nous concevons, prototypons et fabriquons en interne notre propre mécanique, notre électronique et notre firmware. Nous choisissons les meilleurs composants et les intégrons à notre stack firmware en C pour construire un système qui respecte la vie privée des voyageurs dès la conception.
Des gabarits matériels et des logiciels sur mesure, conçus en interne, collectent et envoient des statistiques sur chaque unité dès sa sortie de la ligne de fabrication, ce qui nous permet d'améliorer en continu la qualité du matériel. Le firmware est mis à jour à distance une fois qu'une unité est installée chez quelqu'un ; au fil des ans, ces mises à jour ont amélioré les performances de la batterie de plus de 100 % et ajouté des fonctionnalités que nous n'avions même pas imaginées au lancement. Nous avons aussi construit un service de débogage à distance dans le navigateur, qui nous permet de dialoguer en toute sécurité avec un appareil sur le terrain à des fins de récupération et de diagnostic. Tout cela est rendu possible par un laboratoire matériel bien équipé dans nos bureaux du centre de Malmö.
.png)
Pour gérer des capteurs dans plus de 100 pays, nous avons bâti une suite rigoureuse de tests et d'automatisation afin de réduire le risque de livrer quelque chose qui perturberait un capteur dont dépend l'activité d'un client.
N'importe quel développeur peut faire tourner un environnement complet sur sa machine locale (ou distante), avec des outils pour émuler des utilisateurs, des applications et des capteurs matériels. Notre suite de tests de scénarios en boîte noire exécute le vrai backend dans Docker face à de fausses versions de chaque service tiers avec lequel nous nous intégrons, ce qui nous permet de tester des flux entiers de façon déterministe. Et notre flotte de test interne, composée de plus de 100 capteurs physiques, est continuellement exposée à différents environnements, versions de firmware, configurations logicielles et routeurs.
Les outils et l'automatisation ne sont qu'une moitié ; les workflows sont l'autre. Chaque équipe pratique rigoureusement la revue de code (désormais avec une première passe par l'IA), fait fréquemment du binômage et livre en continu sur toutes les parties de la stack.
En tant qu'ingénieur chez Minut, vous pouvez tout aborder : de l'électronique au firmware faisant tourner du ML sur un minuscule microcontrôleur, jusqu'à un vaste backend TypeScript, aux animations d'une application native, en passant par les agents qui construisent et relisent l'ensemble. Nous sommes une organisation full-stack de bout en bout, nous aimons ce que nous faisons, et nous cherchons des personnes partageant cet état d'esprit pour rejoindre notre équipe d'ingénierie en pleine croissance.
Si cela vous ressemble, jetez un œil à nos postes ouverts.
