GuidesDéveloppement IA
Développer une application IA sur mesure : de l’idée à la production
Une application avant d’être une IA
Les projets qui échouent ont souvent commencé par le modèle. Ceux qui réussissent commencent par le produit : qui s’en sert, pour faire quoi, avec quelles données.
Votons est un bon exemple. C’est une application grand public : un quiz, des fiches, un comparateur, un site, une API et des applications mobiles. L’IA y tient deux rôles précis : un assistant qui répond sur les programmes à partir du texte exact, et des agents qui préparent les cartes du quiz, relues ensuite.
L’architecture type
| Couche | Rôle |
|---|---|
| Interface | Web ou mobile, ce que voit l’utilisateur |
| API | Comptes, droits, règles métier |
| Données | Base de données, documents, index de recherche |
| Orchestration | Enchaîne recherche, appels au modèle et outils |
| Modèle | Appelé par API, remplaçable |
| Observation | Journal, coûts, qualité des réponses |
Le modèle est une couche parmi six. Les cinq autres sont du développement classique, et c’est là que va la plus grande part du travail. Voir Créer une web app.
Choisir le modèle
- Tester sur vos cas, pas sur des classements généraux.
- Un modèle léger pour le simple, un puissant pour le raisonnement.
- La localisation des données quand elle compte.
- La possibilité de changer. Les modèles sont remplacés tous les quelques mois. L’application ne doit pas dépendre d’un seul.
Nos projets n’utilisent pas tous le même : Votons s’appuie sur Mistral, Alfred et Comptoir sur Claude.
Les données
Le modèle ne sait rien de votre activité. On lui apporte ce qu’il faut au bon moment :
- Recherche documentaire pour répondre à partir de textes. Voir RAG.
- Outils pour lire et écrire dans vos systèmes. Voir serveur MCP.
- Ingestion pour garder les données à jour. Votons relève une vingtaine de sources publiques automatiquement.
Tester une application IA
Un modèle ne répond pas deux fois exactement pareil. On ne teste donc pas comme un logiciel ordinaire.
- Un jeu de cas réels avec la réponse attendue.
- Des critères : exactitude, fidélité à la source, ton, refus quand il faut.
- Une évaluation automatique, rejouée à chaque changement de consigne ou de modèle.
- Une relecture humaine sur un échantillon.
Sans ce jeu de tests, chaque amélioration risque de casser autre chose sans qu’on le voie.
Les règles dans le code
Ce qui doit toujours être vrai ne se confie pas à une consigne. La neutralité de Votons est appliquée par le code : positions anonymisées, parité gauche-droite. Les droits d’accès, les plafonds et les validations suivent la même règle.
Mettre en production
- Un plafond de dépense et des alertes.
- Des délais d’attente et un comportement prévu quand le modèle ne répond pas.
- Un journal des demandes et des réponses, dans le respect des données personnelles.
- Un retour utilisateur simple : cette réponse était-elle utile ?
- Un déploiement progressif : équipe interne, petit groupe, tout le monde.
Après la mise en ligne
Une application IA se dégrade si on ne la regarde pas : les contenus changent, les modèles sont remplacés, les usages évoluent. On prévoit la relecture mensuelle des réponses mal notées, la mise à jour du jeu de tests et le suivi des coûts.
Pour le budget, voir Combien coûte un projet IA. Pour démarrer plus petit, voir Lancer un MVP avec l’IA.
Questions fréquentes
- Faut-il entraîner son propre modèle ?
- Presque jamais. Les modèles disponibles par API couvrent la grande majorité des besoins. On les adapte par les consignes, les données fournies au moment de la question et les outils, pas par un entraînement.
- Quel modèle choisir ?
- Celui qui réussit vos cas réels au meilleur coût. On compare deux ou trois modèles sur un jeu de tests tiré de votre activité, et on conçoit l’application pour pouvoir en changer.
- Une application IA peut-elle être hébergée en Europe ?
- Oui. L’application et ses données peuvent tourner sur un serveur européen, et plusieurs fournisseurs de modèles proposent un traitement dans l’Union européenne, dont des acteurs européens.
