La phrase arrive souvent en fin d'audit : "on a déjà un dev, on pourrait le faire en interne."
C'est une réflexion légitime. Et notre réponse n'est pas "non, faites appel à nous". C'est : la vraie question n'est pas "peut-on le faire en interne ?". C'est "est-ce le meilleur usage de l'équipe, et à quel prix réel ?"
Cette distinction change tout le raisonnement.
Ce que "faire en interne" implique vraiment
Un agent IA n'est pas un développement one-shot. C'est là que la plupart des équipes qui se lancent seules sous-estiment le chantier.
Les compétences requises ne sont pas celles d'un dev standard
Un bon développeur web ou backend ne devient pas opérateur d'agents IA en quelques semaines. Les domaines à couvrir sont distincts :
Prompt engineering opérationnel. Pas rédiger un prompt ChatGPT. Concevoir des prompts qui se comportent de manière prévisible à grande échelle, qui gèrent les cas d'exception, qui ne dérivent pas sur 10 000 appels. C'est un métier en soi, avec des patterns spécifiques (chain-of-thought structuré, few-shot calibration, output schemas) que peu de devs maîtrisent d'emblée.
Ops LLM. Comment gérer les timeouts, les hallucinations, le rate limiting des API ? Comment tester la régression d'un prompt quand le modèle est mis à jour par le fournisseur ? Ça demande une instrumentation que la plupart des équipes n'ont pas mise en place.
Infrastructure RAG ou vectorielle. Si l'agent doit raisonner sur vos données internes (documentation, historique client, catalogue produit), il faut une base vectorielle, un pipeline d'indexation, et une logique de récupération fine. Ce n'est pas un "npm install" et c'est fait.
Monitoring. Un agent en production doit être surveillé. Pas seulement "est-ce qu'il tourne ?" mais "est-ce qu'il répond bien ?" Il faut des métriques sur la couverture, les cas d'exception, les temps de réponse, les coûts tokens. La plupart des équipes ne mettent pas ce monitoring en place au départ — et s'en mordent les doigts six mois après.
Maintenance continue. C'est le point le plus sous-estimé. Les prompts dérivent quand le comportement du modèle sous-jacent change. Les intégrations cassent quand les APIs tierces évoluent. Les cas d'exception s'accumulent. Un agent IA demande 1 à 2 heures de maintenance par semaine en régime de croisière — pour un agent simple. Pour un agent complexe, comptez plus.
Ce n'est pas pour décourager l'internalisation. C'est pour que la décision soit prise avec une image réaliste du travail que ça représente.
Quand l'interne est le bon choix
On va être directs : il y a des situations où externaliser n'a pas de sens, et on préfère le dire plutôt que de signer un projet qui ne correspondra pas à ce dont vous avez besoin.
L'internalisation est le bon choix si trois conditions sont réunies simultanément.
Vous avez une équipe technique disponible — pas juste "on a un dev", mais un dev avec de la bande passante réelle sur les 2-3 prochains mois, pas coincé entre deux projets urgents.
Le besoin est récurrent et central. Si l'agent automatisé va toucher un processus au cœur du métier, que vous allez l'itérer pendant des années, et que vous voulez en faire une compétence maison — ça a du sens de construire cette expertise en interne. Sur le long terme, le coût marginal d'un dev qui maîtrise déjà votre stack est inférieur à celui d'une agence externe permanente.
Vous avez la volonté d'en faire une vraie compétence. Pas "on va le faire pour économiser", mais "on veut savoir faire ça". La différence est importante : si l'objectif est l'économie court terme, le calcul est souvent défavorable (courbe d'apprentissage). Si l'objectif est de monter en compétence sur la durée, c'est un investissement qui peut être justifié.
Si ces trois conditions ne sont pas toutes présentes, le calcul se complique.
Quand externaliser fait sens
Le cas de figure le plus fréquent qu'on rencontre est celui d'une PME de 10 à 80 personnes, avec un ou deux profils tech généralistes déjà occupés à plein temps sur le produit ou l'infra existante.
Dans ce contexte, externaliser fait sens pour plusieurs raisons.
Premier projet, courbe d'apprentissage compressée. Monter en compétence sur les agents IA en partant de zéro prend 3 à 6 mois de temps réel. Externaliser un premier projet permet de voir fonctionner un agent en production en 4 à 8 semaines, avec les choix d'architecture déjà arbitrés par des gens qui ont fait des erreurs avant vous.
Pas de compétence IA en interne. Si personne dans l'équipe n'a déjà travaillé sur du prompt engineering ou du RAG, vous n'allez pas juste "faire le projet" — vous allez apprendre un métier en parallèle. Le coût réel de cette option est souvent supérieur à ce qu'un devis externe semble coûter.
Besoin de vitesse. Certains projets ont une contrainte temporelle réelle : répondre à un appel d'offres, lancer avant un concurrent, traiter un backlog qui s'accumule. Dans ces cas, le délai d'apprentissage interne n'est pas acceptable.
Périmètre ponctuel ou incertain. Si vous n'êtes pas sûrs que l'agent va couvrir votre besoin, tester avec une agence limite le risque. Vous déboursez un budget délimité (entre 3 000 et 8 000 € pour un projet de notre côté, selon la complexité) plutôt que d'immobiliser un dev pendant plusieurs mois sur quelque chose qui pourrait pivoter.
Notre rôle dans ces cas : livrer un agent fonctionnel en production, et transférer suffisamment de contexte pour que vous puissiez le maintenir ou l'itérer ensuite.
Le modèle hybride
Pour beaucoup de PME, la vraie bonne réponse n'est ni "tout en interne" ni "tout externalisé en permanence". C'est un modèle en deux temps.
Phase 1 — co-construction. L'agence conçoit, déploie, et documente. Votre équipe technique est impliquée pendant le projet pour comprendre les choix d'architecture, tester les comportements, valider les cas limites. Pas juste en bout de chaîne pour valider, mais dans la boucle dès le départ.
Phase 2 — transfert et autonomie. À la livraison, vous avez un agent en production, une documentation des prompts et des flux, et un ou deux membres de l'équipe qui savent l'opérer. La maintenance courante passe en interne. L'agence reste disponible pour les évolutions structurelles.
Ce modèle coûte un peu plus cher qu'une externalisation sans implication interne, mais il produit un vrai transfert de compétence. C'est souvent ce qu'on propose quand une PME veut aller vite sur un premier projet sans se retrouver dépendante à long terme.
Tableau de décision
| Critère | Interne | Agence | Hybride |
|---|---|---|---|
| Compétence IA disponible en interne | Oui, équipe formée | Non | Dev généraliste à former |
| Urgence du déploiement | Faible (6+ mois) | Forte (4-8 semaines) | Modérée |
| Récurrence et centralité du besoin | Forte, process cœur de métier | Ponctuel ou incertain | Récurrent mais pas encore stabilisé |
| Volonté d'internaliser la compétence | Oui, objectif stratégique | Non, ou pas prioritaire | Oui, mais progressivement |
| Budget initial disponible | Limité (temps interne) | Budgété (3 000–8 000 €) | Intermédiaire |
Aucune ligne n'est un verdict absolu. C'est la combinaison des critères qui oriente la décision.
Les coûts cachés de l'interne
C'est le point qu'on aborde toujours explicitement en audit, parce que les équipes le découvrent trop tard.
Le temps du dev détourné de son vrai job. Si votre dev est la seule personne qui maintient votre infrastructure ou votre produit, chaque heure passée sur l'agent IA est une heure qui ne va pas ailleurs. Ce coût d'opportunité ne figure jamais dans le calcul initial.
La courbe d'apprentissage. Les 3 premiers mois sont les plus coûteux en temps et en erreurs. On estime qu'un dev compétent mais sans expérience agents IA va passer 60 à 100 heures supplémentaires sur un premier projet par rapport à quelqu'un qui a déjà fait le même type de déploiement. À 500-700€/jour de coût salarial chargé, ça représente entre 3 750 et 8 750€ de coût invisible.
Le creep de maintenance. Les agents ne se maintiennent pas seuls. Chaque mise à jour de modèle chez OpenAI, Anthropic ou Mistral peut changer le comportement des prompts. Chaque évolution d'une API intégrée peut casser un flux. Comptez 1 à 2 heures par semaine en régime de croisière — soit 50 à 100 heures par an sur un agent actif.
Le bus factor. Si une seule personne dans l'équipe comprend comment l'agent fonctionne, comment il est configuré, et comment le déboguer — vous avez un risque opérationnel réel. Congé maladie, départ, changement de poste : l'agent devient une boîte noire pour les autres. C'est un scénario qu'on voit régulièrement lors de reprises de projets internes.
Pour être concrets : un projet internalisé sur 3 mois avec un dev à 45 000€/an, qui consacre 40% de son temps au projet, représente environ 9 000€ de coût direct hors infrastructure. Ajoutez la courbe d'apprentissage et le creep de maintenance sur 12 mois, et le coût total se rapproche souvent d'un projet externalisé — sans le bénéfice de la rapidité ni de l'expérience accumulée.
Conclusion
Il n'y a pas de réponse universelle à la question "interne ou agence". Ce qui compte, c'est de prendre la décision avec une image honnête des deux options.
Faire en interne peut être le bon choix si vous avez la capacité technique, la bande passante, et l'ambition d'en faire une compétence stratégique sur la durée. Externaliser fait sens si vous voulez aller vite, que votre équipe est déjà occupée, ou que vous voulez tester avant d'investir.
Ce qui n'a jamais de sens : décider "en interne" parce que ça semble moins cher, sans avoir comptabilisé le temps réel, la courbe d'apprentissage, et la maintenance. Et décider "agence" sans s'assurer que vous repartez avec suffisamment de contexte pour ne pas être dépendants indéfiniment.
La décision n'est pas technique. Elle est organisationnelle.