Pour le CTO et le responsable produit
Nous enregistrons chaque appel à votre API, avec son auteur, l'écran d'origine et sa durée, et vous le voyez dans votre propre tableau de bord. Les données restent dans votre système.
Vous recevez sept écrans de monitoring dans votre tableau de bord et le journal de chaque appel. Le périmètre et le délai de mise en service sont fixés par écrit avant de commencer.
Mis à jour le
Inutile si votre API a peu de trafic ou si vous mesurez déjà chaque endpoint avec ses percentiles.
Sans mesurer chaque appel, on optimise l'endpoint (chaque adresse de l'API) que quelqu'un soupçonne. Avec de vrais utilisateurs, un endpoint met des secondes sur un appel sur cent, un écran demande deux fois la même chose et la moyenne continue de dire que tout va bien. La mesure sous les yeux, on voit lequel est lent, depuis quel écran il est appelé et combien de personnes il touche.
En 30 minutes, nous voyons avec quoi votre API est faite et où vous voulez conserver les données. Vous recevez ensuite par écrit le périmètre et le délai de mise en service.
La capture s'installe dans votre propre API et écrit le journal dans votre Elasticsearch. Mots de passe, jetons, e-mails et localisations sont masqués avant l'enregistrement.
Vous voyez les sept écrans dans votre tableau de bord, avec le reste de votre console. Nous revoyons avec vous, de façon périodique, quel endpoint il vaut mieux optimiser en premier.
Priorité: Haute
Endpoint rapide en moyenne et lent au p99
Exemple du format du rapport, pas d'un client.
Parlons de votre situation ?
Un rendez-vous de 30 minutes pour voir ce que vous avez et ce qu’il vaut mieux revoir en premier.
Les trois sont utiles, chacun pour une chose. L'IA apporte le volume et les personnes le jugement : c'est pourquoi notre revue utilise un outil automatique à base d'IA, supervisé par des développeurs seniors.
La revue est faite par une équipe de développeurs seniors, avec de nombreuses heures de développement et de recherche des erreurs que commettent les IA quand elles programment. Nous connaissons plus de 1 200 points de revue. L'outil automatique à base d'IA les parcourt, et les personnes valident, dirigent et revoient.
Équipe de développeurs seniors
José María Salido, fondateur de Sondeon, en répond
C'est mesurer chaque appel que reçoit votre API : sa durée, sa réponse et son auteur, pour voir où part le temps et ce qui échoue avant qu'un client ne le remarque.
Ce sont des percentiles : le p95 est la durée que 95 % des appels ne dépassent pas, et le p99, 99 %. Ils montrent les appels lents que la moyenne cache : un endpoint peut être rapide en moyenne et faire attendre des secondes un appel sur cent.
Une API en Python avec FastAPI le reçoit tel quel ; en Node, Django ou Spring, la capture s'adapte. Il faut Elasticsearch, et une file de messages si vous en avez déjà une.
La réponse n'est pas affectée : le journal se construit après la réponse, dans un autre fil d'exécution, et transite par une file. Les données sont conservées dans votre propre Elasticsearch : rien ne part chez un tiers.
Le monitoring vous dit lequel optimiser en premier et pourquoi, mesure à l'appui. La correction est à part, et seulement si vous la demandez : votre équipe s'en charge, ou nous si vous nous la confiez.
Le rendez-vous de 30 minutes est gratuit. Le reste dépend du nombre d'API incluses et de leur volume d'appels, et il est fixé par écrit. Il ne le remplace pas : ce health check continu répète à chaque appel ce que regarderait un audit d'API, avec ses percentiles et une revue périodique de ce qu'il faut optimiser en premier.
Apps Flutter créées avec l'IA, testées sur de vrais téléphones iOS et Android, par commande et au toucher, avec leur backend.
Performances, référencement dans les moteurs de recherche et les assistants d'IA (SEO et GEO), accessibilité et sécurité de votre site, mesurés sur la page réelle.
La partie serveur derrière votre app ou votre site : ce que l'API expose, ce qu'elle protège, les en-têtes servis et ce qui finit dans ses logs.
PostgreSQL, Redis, Elasticsearch et RabbitMQ, en lecture seule : structure, index, requêtes lentes, verrous et connexions.
Le serveur où va tourner votre système, revu avant sa mise en ligne : qui y accède, ce qui y tourne et quelles limites cèdent quand il grandit.
Les machines Linux où tourne votre système, mesurées toutes les quelques secondes, pour voir un disque plein ou un conteneur arrêté avant vos utilisateurs.
Remplissez le formulaire et nous vous écrivons par e-mail pour fixer le jour et l'heure. Ce sont 30 minutes pour voir ce que vous avez et ce qu'il vaut mieux revoir en premier.