Ma méthode

Du problème d’un utilisateur à la fonctionnalité livrée.

Mon titre dit développeur iOS. En pratique, je travaille sur tout le produit : utilisateurs, données, specs, design, iOS, Android, backend, tests et release. Les agents IA rendent ça possible à une vitesse qu’une seule personne ne pouvait pas atteindre avant. Cette page explique comment je garde ça rigoureux.

La boucle que je suis, pour chaque fonctionnalité

  1. Écouter

    MoiLa plupart des fonctionnalités partent des utilisateurs : suggestions sur Discord et Reddit, demandes envoyées depuis l’app. Je les confronte aux données (DAU/MAU, rétention, conversion, notes), à la concurrence et à la recherche App Store.

    AgentsLes agents m’aident à lire les retours, étudier le marché et fouiller les analytics.

  2. Spécifier

    MoiJe façonne la fonctionnalité, puis je la challenge jusqu’à ce que chaque cas limite, état et erreur ait une réponse. La spec se termine par des critères d’acceptation qui deviennent des tests. Rien n’est construit avant ma validation.

    AgentsUn agent rédige la spec à partir de notre brainstorm, puis l’interroge pour en trouver les trous.

  3. Designer

    MoiJe design directement dans le vrai support : previews SwiftUI, plusieurs variantes côte à côte. J’en garde une et je supprime les autres.

    AgentsUne variante coûte quelques minutes au lieu de quelques jours, donc je peux aussi tenter l’option audacieuse.

  4. Construire

    MoiJe fixe l’architecture et les frontières, et le build les fait respecter : règles de modules avec Tuist, contrats d’API typés générés depuis OpenAPI. La stack est documentée pour les agents, et des scripts déterministes gèrent tout ce qui doit être exact.

    AgentsClaude Code et Codex écrivent la quasi-totalité du code, souvent en parallèle sur des worktrees séparés, guidés par des skills et un outillage sur mesure.

  5. Vérifier

    MoiJe relis au niveau qui compte : structure, frontières, et si l’architecture sert toujours la stratégie produit. Les snapshot tests sur les écrans clés sont la prochaine étape.

    AgentsLes tests viennent d’abord et doivent échouer avant que l’implémentation les fasse passer, avec des vérifications qu’ils testent vraiment quelque chose. Un second agent, indépendant, relit chaque changement face à la spec.

  6. Livrer et apprendre

    MoiUne release par semaine, parfois plus, derrière des feature flags et avec une mise à jour forcée possible. iOS et Android restent à parité car ils partagent une même spec et des tests unitaires miroirs. Ensuite, les données me disent ce qui a marché.

    AgentsLes agents lisent les analytics et les crashs via des serveurs MCP pour mesurer chaque fonctionnalité et remonter un bug jusqu’aux sessions réelles. Notes de version et traductions en 10 langues sortent du même pipeline.

Architecture

L’architecture, la partie que je ne délègue jamais

Du code écrit par des agents ne reste bon que sur une base propre. Chaque projet que je mène a une architecture claire : couches isolées, dépendances explicites, logique métier couverte par des tests.

Je ne relis plus chaque ligne pour la syntaxe. Je relis la structure : cette frontière est-elle la bonne, ce code est-il au bon endroit, sera-t-il encore facile à changer dans deux ans, colle-t-il toujours à la direction du produit ? C’est là que l’attention d’un ingénieur senior rapporte le plus aujourd’hui.

En équipe, et en solo

Chez Decathlon

Moteur de l’adoption de l’IA dans l’équipe

Je pilote la façon dont l’équipe utilise l’IA : une documentation exploitable par les agents, des skills partagés, des guidelines de revue de code et des sessions internes pour bien l’utiliser sans brûler de tokens.

Le travail dépasse iOS. J’ai conçu le moteur central de notre BFF, qui transforme des milliers de données d’activité par requête en graphiques dans l’app (GPS, fréquence cardiaque, vitesse, allure). Nous définissons ses contrats d’API en OpenAPI avec du code généré des deux côtés : l’app et le backend ne peuvent pas diverger sans que le build échoue. J’ai livré une fonctionnalité de bout en bout, backend et Android compris. Quand le code d’une autre équipe nous bloque, je trouve la cause dans leur dépôt et j’ouvre la pull request moi-même.

Avec Datadog et Amplitude connectés aux agents, un bug remonté par un utilisateur ou un testeur passe vite du symptôme à la cause, parce que je peux le suivre sur toute la stack.

Je travaille au quotidien avec les product managers et les designers, et je pousse des décisions produit et design, pas seulement des tickets.

Sur PokeRadar

Tout le produit, sans équipe autour

Communauté sur Discord et Reddit, analytics, specs, design, iOS, Android, backend temps réel, abonnements et App Store Optimization : tous les rôles, chaque semaine.

La plupart des fonctionnalités viennent directement des suggestions des utilisateurs, et Google Analytics, connecté aux agents, me dit si elles ont marché. L’app est notée 4,8★ et sort une version par semaine, avec 99 % du code écrit par des agents et une architecture que je maîtrise de bout en bout.

Principes

Les détails se racontent mieux de vive voix.

Outillage, specs, organisation de la revue, ce qui a marché et ce qui n’a pas marché : j’en parle volontiers.