Votre application tourne depuis des années. Vos clients y ont leurs habitudes, vos équipes connaissent ses recoins, et un concurrent vient d'annoncer « son » assistant IA. La question arrive au comité de direction sous une forme simple : comment intégrer l'IA dans une application qu'on ne veut surtout pas réécrire ?
Bonne nouvelle, il n'y a presque jamais besoin de la réécrire. Un modèle de langage se branche à côté du code existant, par une API, comme n'importe quel service externe. La difficulté est ailleurs : choisir le bon point d'entrée, borner ce que le modèle a le droit de faire, et savoir ce que cela coûtera chaque mois une fois en production.
En bref
- Intégrer l'IA dans une application existante ne demande pas de refonte : le modèle est appelé par API depuis le code actuel, comme un service de paiement ou d'envoi d'emails.
- Il existe trois points d'entrée, par ordre de complexité : l'appel ponctuel sur une tâche, le RAG sur les données de l'application, l'agent qui agit dans le logiciel.
- Le budget se compte en deux lignes : la construction (de 2 000 à 45 000 euros selon la grille EpickOne 2026) et la consommation mensuelle, facturée au token par le fournisseur du modèle.
- L'OWASP classe l'injection de prompt en tête de son Top 10 2025 des risques des applications à base de LLM, et la consommation non bornée en dixième position.
Comment intégrer l'IA dans une application : les trois points d'entrée
Il y a trois manières de faire entrer un LLM dans un logiciel existant, et elles ne coûtent pas du tout la même chose. Avant toute discussion de modèle ou de fournisseur, situez votre projet sur cette échelle.
1. L'appel ponctuel : une tâche, un bouton
Le cas le plus simple, et souvent le plus rentable. Votre application envoie un texte au modèle et récupère un résultat : résumer un ticket, classer une demande entrante, extraire les champs d'un PDF, proposer une réponse que l'utilisateur relit. Le modèle ne voit que ce que vous lui envoyez à cet instant.
C'est la forme la plus courante d'API LLM dans une application métier. Côté code, on parle de quelques jours. Côté risque, c'est faible, parce que la sortie est relue ou contrôlée avant d'être enregistrée. Dans notre grille, ce palier correspond aux automatisations ciblées : 3 à 8 jours, 2 000 à 6 000 euros.
2. Le RAG : le modèle répond à partir de vos données
Le RAG (génération augmentée par récupération) fait chercher dans vos données les passages utiles avant de laisser le modèle formuler sa réponse. Dans une application métier, ces données sont déjà là : fiches clients, historique des commandes, base documentaire, tickets résolus.
C'est le bon choix quand vos utilisateurs posent des questions dont la réponse se trouve dans le logiciel mais à six clics de distance. Le travail porte surtout sur l'indexation et les droits : un commercial ne doit pas obtenir par l'assistant une marge qu'il ne voit pas à l'écran. Nous avons détaillé le mécanisme dans notre guide de l'assistant IA sur documents internes. Budget indicatif : 10 000 à 25 000 euros.
3. L'agent : le modèle agit dans le logiciel
Ici, le modèle ne se contente plus de répondre. Il déclenche des actions par des fonctions que vous exposez : créer une fiche, modifier un statut, envoyer une relance. C'est le palier qui rapporte le plus quand il fonctionne, et celui où une erreur se paie cher, parce qu'une action mal décidée s'exécute vraiment.
Notre position est tranchée : on n'y va jamais d'emblée. Un agent se construit sur un appel ponctuel qui a fait ses preuves, et son autonomie s'élargit sur des traces d'exécution, jamais sur une démonstration. Comptez 18 000 à 45 000 euros pour un agent relié à votre système d'information.
L'architecture qui tient en production
Une intégration solide repose sur une règle : le code de votre application reste le chef, le modèle propose. Tout ce qui engage l'entreprise passe par une vérification déterministe ou par un humain.
Concrètement, quatre briques reviennent sur chaque projet que nous livrons.
- Une couche d'accès au modèle isolée. Votre application parle à une interface maison, pas directement au SDK du fournisseur. Changer de modèle, ajouter un modèle de secours ou brancher un faux modèle pour les tests devient une ligne de configuration.
- Des sorties structurées. On demande au modèle de remplir un format défini (un appel d'outil, un JSON validé par un schéma) plutôt que du texte libre. Le code vérifie chaque champ avant de l'utiliser.
- Une machine à états côté serveur. Si le modèle suggère l'étape suivante d'un parcours, le serveur décide si cette transition est autorisée.
- Un budget plafonné. Chaque appel est compté en tokens, chaque jour a un plafond de dépense, et au-delà l'application bascule sur un chemin sans IA.
L'avis de Laurent, Lead Développeur back-end & IA chez EpickOne : « La première question que je pose n'a rien de technique : que se passe-t-il quand le fournisseur ne répond pas ? Si la réponse est "l'écran reste bloqué", l'intégration n'est pas finie. Sur notre propre assistant, une panne du modèle renvoie le visiteur vers le formulaire de contact classique, avec un message écrit par un humain. Le jour où l'API tombe, le prospect ne reste pas devant un écran figé, et c'est tout ce qui compte. »
Votre application tourne, et vous ne savez pas par où faire entrer l'IA ? Nous vous proposons un cadrage d'intégration IA offert : 45 minutes sur votre application et vos données. Vous repartez avec le point d'entrée qui a du sens chez vous, ce qu'il faut toucher dans le code existant, et un ordre de grandeur de coût mensuel. Réserver le cadrage d'intégration IA offert.
Ce que coûte une intégration IA sur mesure : deux budgets distincts
Intégrer l'IA générative dans un logiciel se paie sur deux lignes : la construction, payée une fois, et la consommation du modèle, payée chaque mois. Les dirigeants qui nous consultent connaissent presque toujours la première et sous-estiment la seconde.
La construction suit les trois paliers ci-dessus. Le détail par type de projet est dans notre article sur le coût d'une intégration IA pour une PME.
La consommation se facture au token, en entrée et en sortie. Faisons le calcul avec Claude Haiku 4.5, affiché par Anthropic à 1 dollar le million de tokens en entrée et 5 dollars en sortie. Un appel qui envoie 3 000 tokens de contexte et reçoit 500 tokens de réponse coûte environ 0,0055 dollar. À 10 000 appels par mois, cela fait 55 dollars. Le même volume sur un modèle haut de gamme multiplie la facture par cinq ou dix. Notre comparatif des prix des modèles IA tient ces tarifs à jour, et la page sur la vitesse des modèles aide à choisir quand le temps de réponse compte pour vos utilisateurs.
Le levier le plus efficace sur cette ligne tient en une phrase : ne pas appeler le modèle quand une règle suffit. Sur le traitement documentaire décrit plus bas, le routage déterministe absorbe la majeure partie du flux sans aucun appel, et le modèle ne traite que ce que les règles ne savent pas trancher.
Intégrer l'IA dans une application : cinq pièges qui coûtent cher après la mise en ligne
Ces pièges ont un point commun : aucun ne se voit pendant la démonstration.
1. Les données clients qui partent sans que personne l'ait décidé. Chaque appel envoie du texte chez le fournisseur du modèle. Si ce texte contient des noms, des IBAN ou des données de santé, il faut le savoir, le documenter dans votre registre RGPD, et masquer ce qui n'a pas besoin de partir. Notre assistant masque par exemple les numéros de carte bancaire, les IBAN et les numéros de sécurité sociale avant tout stockage.
2. L'injection de prompt. Un utilisateur, ou un document qu'il dépose, peut contenir des instructions qui détournent le modèle. L'OWASP la classe en première position (LLM01) de son Top 10 2025. La parade relève de l'architecture : le modèle n'a accès qu'aux fonctions dont il a besoin, et le serveur contrôle chaque action. Le risque voisin, l'autonomie excessive (LLM06), se traite de la même façon.
3. La dépendance au fournisseur. Un modèle est retiré, un tarif change, une API tombe. Sans couche d'abstraction, chacun de ces événements devient un chantier. Avec, c'est une variable d'environnement et un modèle de secours déjà testé.
4. L'absence d'évaluation. « Ça marche sur mes dix exemples » ne mesure rien. Constituez un jeu de cas réels avec la réponse attendue, et rejouez-le à chaque changement de prompt ou de modèle. Sans ce jeu, vous découvrirez les régressions par vos clients.
5. La consommation non bornée. Un robot qui martèle votre formulaire, une boucle qui rappelle le modèle, et la facture du mois tombe en une nuit. L'OWASP en fait son risque LLM10. Plafond journalier, limite de requêtes par adresse IP, nombre de tours maximum par conversation : trois réglages, une après-midi de travail.
S'y ajoute une obligation légale pour les interfaces conversationnelles : l'article 50 de l'AI Act impose d'informer la personne qu'elle échange avec un système d'IA, sauf si c'est évident dans le contexte.
Deux intégrations que nous avons livrées
Les deux exemples qui suivent sont des projets réels. Le premier se vérifie en ligne, le second est anonymisé.
Un assistant branché sur un site Symfony en production. Contexte : notre propre site, epickone.fr, une application Symfony existante. Action : le 20 juin 2026, nous y avons ajouté un assistant de pré-qualification accessible depuis le QR code de nos cartes de visite, sans toucher au reste du site. La clé d'API ne quitte jamais le serveur, la première question est écrite en dur (aucun appel au modèle au chargement de la page), et le parcours est piloté par une machine à états côté serveur. Chaque appel est pré-débité sur un budget journalier avant d'être envoyé, puis recalé sur la consommation réelle. Résultat : un modèle principal et un modèle de secours déclarés dans la configuration, et un retour au formulaire classique dès que le budget, le fournisseur ou un refus du modèle l'exigent.
Un agent dans la chaîne documentaire d'un opérateur de ventes aux enchères de véhicules. Contexte : quatre sites, environ 2 000 véhicules en parc, une boîte mail partagée d'où partaient toutes les ressaisies vers l'ERP. Action : huit workflows ajoutés autour de l'ERP existant, sans le remplacer, avec validation humaine véhicule par véhicule au démarrage. Résultat : 195 tests automatisés, et le 6 août 2026 la mise à jour des prix et la création de véhicule sont passées en automatique, après plusieurs semaines de traces vérifiées. Nous ne publions pas de gain de temps chiffré, faute de l'avoir mesuré. L'architecture complète est dans le cas client sur le traitement documentaire.
Par quoi commencer, côté application
Choisissez une seule tâche, dans l'application, où vos utilisateurs perdent du temps sur du texte : lire, classer, résumer, retrouver. Mesurez combien de fois par mois elle se produit. Ce chiffre vous donne à la fois l'intérêt du projet et son coût de consommation.
Ensuite seulement, regardez le code. Si l'application a été générée en partie par un outil d'IA ou passée entre les mains de prestataires successifs, un passage par notre méthode d'audit d'une application générée par IA évite de brancher un modèle sur des fondations fragiles. Si vos outils métier ne se parlent pas encore, commencez par l'article sur les API et intégrations vers le CRM ou l'ERP. Et le volet organisationnel, qui pilote et quel cas d'usage passe en premier, est traité dans notre guide pour intégrer l'IA côté direction. Notre façon de concevoir ces projets est résumée sur la page Projet IA, et vous pouvez rencontrer les développeurs qui branchent ces intégrations, entre Toulouse et Paris.
Votre application est prête à recevoir l'IA, ou presque ? Prenons 45 minutes ensemble sur votre application et vos données. Nous regardons le point d'entrée le plus rentable, ce que le modèle aurait le droit de faire, et la facture mensuelle à prévoir. Le cadrage est offert, et il arrive qu'il conclue qu'une règle simple suffit. Demander le cadrage d'intégration IA.