Comment j'ai bâti une application sur 3 plateformes avec 19 agents d'IA

J'ai lancé Palpite PRO au début de mai 2026. Début juin, l'application était déjà dans l'App Store et sur Google Play. Aujourd'hui, elle fonctionne sur iOS, Android et le Web, en 8 langues, avec des classements en direct et des analyses rédigées par l'IA.

Il y a quelques années, un tel rythme aurait été difficile à imaginer. Ce qui a changé, ce n'est pas que l'IA écrive le code. C'est la façon dont j'ai organisé le travail autour d'elle.

Ce qu'est Palpite PRO

Palpite PRO est un jeu social gratuit : des amis créent des ligues, prédisent le score des matchs avant le coup d'envoi et grimpent dans un classement en direct. Pas de cotes, pas d'argent, juste pour l'honneur.

Derrière cette idée simple, il y a beaucoup de logiciel :

• Une API, des tâches en arrière-plan pour le calcul des points et le statut des matchs en direct, et des mises à jour en temps réel
• Trois applications Web : le site public, l'application des membres et un panneau d'administration
• Des applications natives iOS et Android, publiées par des pipelines automatisés vers les boutiques
• Des fonctions d'IA : de courtes analyses sur chaque ligue et de l'aide pour importer de nouveaux championnats

Le processus : la spécification d'abord, les agents ensuite, et moi aux commandes

Chaque changement, petit ou grand, suit le même chemin. Je décris ce que je veux en langage clair. L'IA en fait une spécification écrite, et je fais des allers-retours jusqu'à ce qu'elle dise exactement ce que je veux. Vient ensuite un plan d'implémentation, que je révise de la même façon. Ce n'est qu'alors que le code est écrit, et il est revu avant de m'arriver.

Chaque étape a son spécialiste. Le projet compte 19 agents d'IA, chacun avec un seul rôle : rédiger les spécifications, l'architecture, le front-end, la revue de sécurité, les tests, la traduction, la revue UX, les mises en production, et plus encore. Un assistant unique qui « fait tout » oublie des choses. Un spécialiste avec un mandat clair, non.

Quelques chiffres du projet jusqu'ici :

Les tests comptent plus qu'on ne le croit. Quand l'IA écrit la majeure partie du code, ce sont eux qui montrent qu'il fait toujours ce que vous avez demandé, surtout trois mois plus tard.

Ce que seule une personne a remarqué

La leçon la plus utile est venue d'un incident évité de justesse.

J'ai mis en place un nouveau processus de mise en production : au lieu de recompiler l'application pour les boutiques, il promouvrait exactement la version déjà validée par les tests. Logique. Toutes les vérifications automatiques ont réussi.

Puis j'ai posé une question : la version promue utilise-t-elle les paramètres de production? Non. La version testée pointait vers le serveur de préproduction. Si elle avait été publiée, tous les utilisateurs auraient été connectés au mauvais backend.

Aucun agent ne l'a signalé, parce que rien n'était techniquement brisé. Il fallait quelqu'un qui sache à quoi servait cette mise en production. C'est pourquoi chaque étape de mon processus comporte une validation humaine. L'IA fait le gros du travail; les décisions restent les miennes.

La base de connaissances : apprendre au projet à se souvenir

Au début, le même plantage Android est revenu quatre fois. Chaque fois, l'analyse repartait de zéro et trouvait la même cause profonde.

Maintenant, chaque bug qui mérite d'être retenu devient une courte fiche dans une base de connaissances au sein du projet : ce qui s'est passé, pourquoi, et comment l'éviter. Les agents la lisent avant de planifier un nouveau travail. Il y a maintenant plus de 60 leçons, et la même erreur se reproduit rarement.

Quelques-unes de mes préférées :

• Tous les matchs « reportés » au coup d'envoi. Le fournisseur de données sportives met quelques minutes à indiquer qu'un match a commencé. Le système lisait « pas commencé » après le coup d'envoi et marquait tous les matchs de la journée comme reportés. La correction était simple; repérer le problème demandait quelqu'un qui suive le soccer.
• Des pannes d'IA qui ressemblaient à des fonctionnalités. Quand le fournisseur d'IA atteignait sa limite de quota, l'application passait en silence à un texte générique. Les utilisateurs ne pouvaient pas distinguer « temporairement en panne » de « pas configuré ». Un plan B, c'est bien, mais un plan B silencieux cache les problèmes.
• Un quota gaspillé pour rien. Une vérification en arrière-plan interrogeait le service de données sportives chaque minute, même sans aucun match en cours.

Ce que ça signifie si vous commencez avec l'IA

Vous ne bâtissez sans doute pas une application sur trois plateformes. Mais ces leçons valent pour toute entreprise qui adopte l'IA :

1. Écrivez ce que vous voulez avant de le demander. Un mandat clair vaut mieux qu'un prompt astucieux. Si vous ne pouvez pas décrire le résultat, l'IA ne peut pas le livrer.
2. Gardez une personne à chaque point de décision. L'IA est rapide et infatigable, mais elle ne sait pas à quoi sert votre entreprise. Révisez, questionnez et renvoyez le travail au besoin.
3. Donnez une mémoire à l'IA. Gardez vos décisions, vos règles et vos leçons au même endroit, rédigées autant pour les personnes que pour l'IA. Chaque erreur documentée est une erreur que vous ne payez pas deux fois.
4. Surveillez les coûts d'utilisation. Les services d'IA et de données facturent à l'usage. Mesurez ces coûts dès le premier jour, et rendez les pannes visibles au lieu de les masquer.

L'IA n'a pas remplacé la réflexion. Elle a éliminé une bonne partie de la saisie, pour que je consacre mon temps aux décisions qui comptent.

Envie de voir tout le processus? Voici comment j'utilise l'IA, étape par étape.