Votre agent fonctionne. Les leads sont qualifiés, les tickets triés, les factures traitées. Le builder no-code ou le workflow n8n que vous avez mis en place il y a trois mois a fait ses preuves — et commence maintenant à montrer des fissures.
Les temps de réponse ont augmenté. Une mise à jour d’une API tierce a cassé deux flows mardi dernier, et votre équipe a passé une demi-journée à corriger manuellement des configurations de nœuds. Les rate limits de la plateforme sont désormais un vrai goulot d’étranglement aux heures de pointe, et la prochaine fonctionnalité dont vous avez besoin — interroger une base de données interne propriétaire, enchaîner plusieurs étapes de décision avec mémoire — se situe juste en dehors de ce que l’UI du builder peut exprimer proprement.
C’est le moment de la migration. Décider si et comment migrer de votre plateforme no-code d’agents IA vers une architecture custom est un choix conséquent. Bien fait, il préserve tout ce que vous avez prouvé et ajoute tout ce dont vous avez besoin. Mal fait, c’est une réécriture qui coûte deux fois plus de temps et efface des mois d’apprentissage par l’itération.
Les Signaux qui Justifient une Migration (Pas Seulement une Tentation)
Vouloir plus de contrôle n’est pas une raison suffisante pour tout reconstruire. Le code custom a des coûts réels : développement initial plus long, plus de responsabilité sur l’infrastructure, et aucun vendor à appeler quand quelque chose casse. Avant de migrer, vérifiez donc si vous atteignez de vraies limites structurelles — ou si la plateforme a encore de la marge.
Déclencheurs structurels à prendre au sérieux :
- Profondeur d’intégration. Votre workflow doit lire ou écrire dans des systèmes internes (ERP, bases de données propriétaires, APIs legacy) avec lesquels la plateforme ne peut pas s’authentifier proprement, ou pour lesquels vous contournez des limitations avec des étapes intermédiaires fragiles.
- Volume et fiabilité. L’agent traite suffisamment de transactions pour que les rate limits de la plateforme ou les SLA d’infrastructure partagée dégradent significativement les performances. Si un engorgement de la queue un lundi matin chargé vous coûte du chiffre d’affaires réel, c’est structurel, pas accidentel.
- Complexité de la logique. Le workflow dont vous avez besoin implique une logique conditionnelle ramifiée, du raisonnement multi-étapes avec état partagé, ou de la mémoire entre sessions — et l’exprimer proprement dans la plateforme n’est pas possible ou nécessite des contournements que les futurs mainteneurs ne comprendront pas. Les builders purement no-code (Zapier et outils similaires) ont les contraintes les plus strictes ; les plateformes low-code comme n8n ont ajouté de la mémoire native et de l’orchestration stateful, mais là aussi la logique multi-agent complexe dépasse souvent ce que l’éditeur visuel peut exprimer clairement.
- Résidence des données ou conformité. Vos exigences légales ou de protection des données (LPD, RGPD) restreignent les transferts de données transfrontaliers d’une manière qui peut rendre certaines plateformes cloud non conformes — ou qui, en pratique, impose que les données restent dans une juridiction spécifique. Des règles sectorielles telles que les circulaires FINMA ou la réglementation sanitaire peuvent imposer des exigences de localisation plus strictes par rapport à ces lois de base.
- Coûts à l’échelle. La tarification d’une plateforme qui fonctionnait à 500 exécutions mensuelles de l’agent est différente à 50 000. Si les coûts par tâche s’accumulent plus vite que la valeur qu’ils génèrent, l’arithmétique du TCO a changé.
Aucun de ces signaux n’est une crise pris isolément. Deux ou trois ensemble méritent qu’on agisse.
Pour une analyse plus complète de ce qui gouverne le calcul build-vs-buy en premier lieu, le framework Build vs Buy pour les agents IA couvre la décision initiale en détail. Cet article part du moment où cette décision bascule vers le custom.
Ce qu’il Faut Conserver, Ce qu’il Faut Reconstruire
L’instinct lors d’une migration est de repartir de zéro — une codebase propre, une architecture correcte, aucun contournement désordonné. Résistez-y. Votre prototype existant contient quelque chose de précieux : un modèle validé du workflow réel, incluant tous les cas limites que la réalité vous a envoyés.
Ce qu’il faut conserver :
- La logique métier — les règles conditionnelles, les seuils d’escalade et les décisions de routage que votre équipe a affinés par l’itération. Documentez chaque branche non évidente avant de toucher au code.
- La couche de prompts — si vous avez optimisé des system prompts et des exemples few-shot pour votre domaine spécifique, c’est le fruit d’un travail difficile. Migrez-les avec soin et testez les outputs par rapport à votre baseline avant de considérer une version comme définitive.
- La taxonomie des échecs — chaque fois que le prototype a mal fonctionné et que quelqu’un l’a détecté, vous avez appris quelque chose. Votre checklist QA pour le build custom devrait être construite directement à partir de ces incidents.
Ce qui doit généralement être reconstruit correctement :
- Authentification et gestion des secrets — les plateformes no-code — en particulier les configurations self-hosted — stockent souvent les credentials d’une manière qui peut ne pas répondre à vos standards de sécurité de production spécifiques. Reconstruisez cela depuis le début en vous appuyant sur le secret store de votre infrastructure.
- Gestion des erreurs et retries — les builders de plateformes abstraient les modes de défaillance. Le code custom vous force à être explicite sur ce qui se passe quand un appel API expire, qu’un modèle retourne une réponse malformée, ou qu’une queue s’engorge. Cette explicitation est un avantage une fois que vous l’avez.
- Observabilité — vous avez probablement un logging minimal du prototype. Le code custom signifie que vous pouvez instrumenter exactement ce qui compte : latence par étape, consommation de tokens par exécution, taux d’erreur par catégorie. C’est là que les équipes de migration sous-investissent le plus souvent — et ce dont elles regrettent le plus de s’être privées.
Une Migration Échelonnée qui Ne Bloque Pas la Production
La stratégie de migration la plus risquée est celle qui consiste à tout mettre hors ligne, reconstruire en parallèle pendant deux mois, puis effectuer une seule bascule. Évitez-la. Une approche échelonnée demande plus de temps de planification, mais délivre presque toujours plus rapidement et avec moins de risques.
Une séquence de migration qui fonctionne :
-
Geler le prototype. Arrêtez d’ajouter des fonctionnalités à la version sur la plateforme. C’est désormais une implémentation de référence, pas un produit. C’est plus facile à dire qu’à faire — les parties prenantes continueront à demander des améliorations — mais le scope creep sur un système que vous remplacez multiplie le coût de migration.
-
Extraire et documenter la logique canonique. Avant d’écrire une ligne de code custom, rédigez une spécification de ce que l’agent est censé faire : inputs, branches de décision, outputs, conditions d’erreur. Traitez cela comme la source de vérité sur laquelle les deux versions doivent s’accorder.
-
Reconstruire d’abord l’infrastructure core, ensuite la logique. Configurez l’environnement custom — hébergement, CI/CD, logging, secrets — avant de porter toute logique de workflow. Migrer la logique sur une infrastructure instable produit des bugs subtils difficiles à tracer.
-
Faire tourner la version custom en shadow. Acheminez le trafic de production réel vers les deux systèmes simultanément, la version sur la plateforme gérant les réponses effectives et la version custom tournant silencieusement. Comparez les outputs. Quand les taux de concordance sont élevés et que le taux d’échec de votre version custom est acceptable, vous êtes prêt à basculer.
-
Déplacement progressif du trafic. Commencez par envoyer 5 à 10 % du trafic vers la version custom pendant que la plateforme gère le reste. Surveillez les régressions dans vos métriques clés pendant au moins un cycle d’activité complet avant d’augmenter la part. Un pic d’erreurs à 2h du matin un mercredi peut ne pas apparaître avant que vous soyez en production depuis une semaine.
-
Décommissionner délibérément. Laissez la version de la plateforme tourner en mode lecture seule ou standby pendant 30 jours après la bascule complète. C’est une assurance peu coûteuse contre les cas limites qui n’apparaissent que dans des scénarios à faible fréquence.
Le Changement Opérationnel que Personne Ne Planifie
Quand vous migrez d’une plateforme no-code d’agents IA vers du code custom, vous ne changez pas seulement de technologie — vous changez qui assume la responsabilité opérationnelle.
Sur une plateforme, le vendor gère la fiabilité de l’infrastructure, les mises à jour de version pour les connecteurs LLM sous-jacents, et la plupart des patches de sécurité. Avec du code custom, tout cela incombe à votre équipe ou à votre partenaire de développement.
C’est gérable, mais il faut que ce soit explicite. Avant de migrer, répondez à ces questions :
- Qui surveille l’agent en production ? Quels sont les seuils d’alerting ?
- Quel est le processus de réponse aux incidents quand l’agent commence à mal fonctionner à grande échelle ?
- Qui gère la relation avec le fournisseur de modèle, et comment une modification de l’API du modèle est-elle absorbée ?
Les équipes qui sautent ces conversations les découvrent souvent au pire moment possible — lors d’un incident de production un vendredi après-midi.
L’article Gérer les agents IA en production couvre le playbook opérationnel en détail. Il vaut la peine d’être lu avant de finaliser votre plan de migration, pas après.
Combien de Temps Cela Prend-il Vraiment ?
Cela dépend de la complexité de l’agent et de la qualité de la documentation du prototype. Pour un workflow à agent unique de complexité modérée — un agent de qualification de leads tournant sur un CRM, par exemple — une migration échelonnée prend typiquement quatre à huit semaines, shadow-run et déplacement du trafic inclus.
Ce délai s’allonge si le prototype a des cas limites non documentés, si les intégrations custom nécessitent de négocier l’accès API avec les responsables des systèmes internes, ou si la revue de conformité pour le nouvel environnement d’hébergement prend plus de temps que prévu.
Sauter la phase de shadow-run pour comprimer le planning est une erreur courante. Deux semaines de fonctionnement parallèle coûtent peu comparées à un incident de production que personne n’a détecté en test.
Le Lock-In de la Plateforme Pendant la Migration
La fenêtre de migration est le moment où vous êtes le plus exposé au lock-in de la plateforme. Vous dépendez de la plateforme pour le trafic de production pendant que la version custom est en cours de construction. Si le vendor change sa tarification, restreint l’accès API ou subit une panne dans cette fenêtre, vos options sont limitées.
Cartographiez exactement ce dont vous dépendez dans la plateforme — et quelles dépendances sont faciles à répliquer par rapport à celles qui sont difficiles — avant de commencer. L’article Lock-in des plateformes d’agents IA détaille les catégories de risque spécifiques.
Quand la Migration N’est Pas la Bonne Réponse
La migration n’est pas toujours le bon choix, même quand vous rencontrez des frictions. Deux scénarios où rester sur la plateforme (ou passer à une autre) a plus de sens qu’aller vers du custom :
Le workflow est genuinement simple. Si votre agent fait une seule chose, de manière fiable, et que la plateforme la gère sans limitations significatives, l’overhead opérationnel du code custom n’est pas justifié. Les plateformes méritent leur coût à faible et moyenne complexité.
Le business case ne s’est pas encore stabilisé. Si le workflow change encore significativement chaque mois — inputs différents, logique de décision différente, outputs différents — le coût de maintenance d’une codebase custom pendant que les exigences évoluent est élevé. Prouvez d’abord la stabilité sur la plateforme. L’article Quand les builders no-code d’agents IA atteignent leurs limites propose un cadre utile pour distinguer « nous avons atteint le plafond » de « nous n’avons pas encore construit le bon workflow ».
Migrer avec un Partenaire ou en Interne
Une migration de ce type est réalisable en interne si vous avez des ingénieurs avec une expérience en AI/ML en production et de la disponibilité. La plupart des PME n’ont pas les deux en même temps.
Travailler avec un partenaire de développement présente un avantage spécifique à l’étape de la migration : une équipe qui a déjà migré des agents de plateformes vers du code custom a déjà rencontré la plupart des modes de défaillance — et dispose des templates, des outils de test et des runbooks opérationnels déjà construits. Ce savoir institutionnel comprime une migration de 12 semaines en 6.
Chez Orange ITS, nous avons structuré le développement d’agents IA custom précisément autour de ce type d’engagement de migration : en partant de votre prototype existant, en extrayant ce qui fonctionne, en reconstruisant ce qui ne fonctionne pas, et en remettant un système de production avec une observabilité complète et un handover opérationnel que votre équipe peut gérer de manière autonome.
Prêt à Planifier Votre Migration ?
Si votre plateforme d’agents montre les fissures décrites ci-dessus — et que vous souhaitez une évaluation lucide de ce qu’une migration impliquerait pour votre configuration spécifique — un appel de 30 minutes avec notre équipe est le bon point de départ.
Nous examinerons votre workflow actuel, identifierons les déclencheurs structurels les plus pertinents dans votre contexte, et vous donnerons une vision honnête de si la migration a du sens maintenant, plus tard, ou pas du tout.
Prenez rendez-vous avec Orange ITS — pas de slides, pas de pitch commercial, juste une conversation technique sur votre système réel.