
Les données permettant d'expliquer la lenteur d'un point de terminaison se trouvent généralement déjà dans ton projet. Blackfire fournit le profil. Le profilage continu fournit le « flame graph ». Les chiffres de trafic indiquent quel chemin est concerné. Le code est dans Git. Ce qui te prend tout l'après-midi, c'est de mettre ces quatre éléments côte à côte et de déterminer quelle fonction est en cause.
C’est justement pour cet après-midi-là que l’Upsun Performance Agent a été conçu. C’est un agent IA qui s’exécute au sein de ton projet Upsun, lit ces signaux provenant d’un environnement déployé et génère un rapport concis : ce qui est lent, pourquoi, dans quelle mesure ça affecte les utilisateurs, ainsi qu’un diff que tu peux appliquer. Il a été lancé en août et est désormais disponible sur Upsun Cloud.
Quand on a interrogé nos clients en début d’année sur la façon dont ils gèrent les problèmes de performances, le même scénario revenait sans cesse. Ils connectent Blackfire, ouvrent un graphe d’appels, et ne comprennent pas ce qu’ils regardent. Du coup, le travail est mis en attente.
Une solution courante consistait à coller la sortie de Blackfire dans ChatGPT et à lui demander de l’expliquer. Ça marche jusqu’à un certain point, mais un LLM générique ne voit que le profil. Il ne voit pas le code, le trafic qui détermine quel point de terminaison est important, ni comment l’appli est déployée. Tu obtiens une explication des symptômes, mais pas de solution.
Upsun regroupe toutes ces informations au même endroit.
Tu ajoutes trois lignes à .upsun/config.yaml:
tasks:
performance-agent:
base: "performance-agent"
Tu ajoutes un ANTHROPIC_API_KEY ou OPENAI_API_KEY en tant que variable d’environnement sensible, tu lances l’exécution, et un bouton « Exécuter » pour l’agent apparaît dans la console, sous la fiche « Tâches » de l’environnement. Choisis l’application (ou le worker) à analyser, sélectionne une plage horaire, et c’est parti. Tu peux aussi déclencher la même opération depuis l’API si tu préfères :
upsun e:curl -p <project-id> -e <environment> -X POST /tasks/performance-agent/run \
--json '{"variables":{"env":{"AGENT_APPLICATION":"<app-name>"}}}'
L’agent démarre sous la forme d’un conteneur de tâches, ce qui signifie qu’il n’existe que pendant son exécution. Il récupère les profils Blackfire et les données de profilage en continu pour la fenêtre temporelle que tu choisis (entre 15 minutes et sept jours), analyse le trafic pour classer les points de terminaison par ordre d’importance, clone ta source et détermine les mesures à prendre concernant les points sensibles. Une fois l’opération terminée, le conteneur disparaît et le rapport s’affiche dans l’onglet « Rapport » de l’activité de la tâche dans la console.
Une exécution prend généralement quelques minutes.
Un paragraphe de synthèse, une recommandation en une ligne sur ce qu’il faut corriger en priorité, puis jusqu’à cinq constatations classées par impact sur l’expérience utilisateur (tu peux définir ce nombre entre 1 et 15). Chaque constatation comporte une priorité, une description en langage clair de la cause première, les preuves utilisées par l’agent et une modification recommandée, généralement accompagnée d’un diff.
Chaque rapport suit la même structure, ce qui est important quand tu compares plusieurs exécutions ou que tu en transmets un à un collègue qui ne l’a pas lancé.
Il n’y a pas de ligne de facturation Upsun pour l’agent. Deux éléments ont un coût.
La première, c’est le conteneur de tâches sur lequel il s’exécute, facturé à la seconde comme n’importe quel autre conteneur de ton projet, et uniquement pendant qu’il est en cours d’exécution.
La seconde, ce sont les jetons de modèle, qui apparaissent sur ta propre facture Anthropic ou OpenAI. On ne revend pas l’accès aux modèles. D’après nos estimations issues des tests, ça coûte environ entre 0,25 $ et 0,85 $ par exécution sur gpt-5.6-terra, de 0,65 $ à 2,20 $ sur claude-sonnet-5, et entre 1,00 $ et 2,90 $ sur claude-opus-4-8, qui est la valeur par défaut.
Apporter ta propre clé demande plus de configuration que ce qu’un assistant intégré t’impose. On en est conscients. En contrepartie, tu vois exactement ce que coûte chaque exécution et c’est toi qui choisis le modèle. Le profil et le code de ton application ne transitent jamais par un compte de modèle qu’on contrôle, ce qui importait davantage à certaines équipes avec lesquelles on a discuté que le prix.
Ça ne modifie pas ton code, et ça n’ouvre pas de pull request. Lors des entretiens, huit personnes sur dix nous ont dit qu’elles voulaient une explication qu’elles pourraient examiner plutôt qu’une correction appliquée à leur place, au moins au début ; c’est donc comme ça qu’on a conçu la première version.
Rien ne se passe à moins que tu ne le demandes. Il n’y a pas de planning, et l’agent ne se déclenche pas quand un indicateur dépasse un seuil. C’est toi qui le déclenches, ou tu appelles l’API depuis ton propre planificateur.
Et ça marche mieux avec plus de données de profilage. Chaque projet inclut 15 minutes de profilage continu, ce qui est suffisant pour une exécution mais ne couvre que les dernières minutes d’activité. L’extension de profilage continu conserve les données pendant 30 jours, ce qui permet à l’agent de détecter les problèmes qui s’accumulent au fil du temps, comme un chemin lent en période de pic de trafic ou un job batch hebdomadaire.
C’est le premier d’une série. Un agent d’analyse des logs est prévu prochainement. Il s’exécute sur le même environnement d’exécution de conteneurs de tâches et génère des rapports au format identique ; ainsi, une fois que tu en auras lu un, tu sauras comment lire le suivant.
Si tu es sur Upsun Cloud et que tu envoies déjà des données Blackfire, la documentation te permettra de passer de zéro à un premier rapport en environ cinq minutes. Dis-nous ce qu’il a détecté.