SLO pour outils internes : définissez des objectifs mesurables de disponibilité et de latence, puis reliez-les à des alertes qu'une petite équipe peut gérer sans s'épuiser.
Les outils internes semblent petits parce que l'audience est réduite. L'impact, souvent, ne l'est pas : si votre tableau de bord ops est en panne, les commandes s'arrêtent ; si votre console support est lente, les clients attendent ; si le panneau d'administration casse, les corrections s'accumulent.
Sans objectifs de fiabilité clairs, chaque panne devient un débat. Une personne hausse les épaules pour un bug de 10 minutes, une autre le traite comme une crise. Vous perdez du temps dans des discussions bruyantes, des priorités floues et des travaux surprises au pire moment.
Les SLO règlent ça en posant des attentes simples et mesurables. Ils répondent à deux questions pratiques : qu'est-ce qui doit fonctionner, et à quel niveau pour que les gens puissent faire leur travail.
Le coût caché du « on gardera ça plutôt stable » apparaît vite. Le travail s'arrête pendant que les équipes attendent que l'outil revienne. Les sollicitations du support se multiplient parce que personne ne sait ce qui est normal. Les ingénieurs sont entraînés dans des réparations urgentes au lieu d'améliorations planifiées. Les Product Owners cessent de faire confiance au système et demandent des sauvegardes manuelles. Les petits problèmes traînent parce qu'ils ne franchissent jamais une limite claire.
Vous n'avez pas besoin d'un programme complet de fiabilité. Une petite équipe peut commencer par quelques objectifs centrés sur l'utilisateur comme « la connexion fonctionne » ou « les résultats de recherche s'affichent rapidement », plus un petit ensemble d'alertes reliées à une action réelle.
Ceci vaut quel que soit le mode de construction de l'outil. Si vous utilisez AppMaster (appmaster.io) pour créer des apps internes, choisissez les actions sur lesquelles les gens comptent, mesurez disponibilité et temps de réponse, et alertez seulement quand cela affecte le travail.
Ces trois termes se ressemblent, mais ce sont des langages de fiabilité différents. Les confondre est une source courante de confusion.
Un SLI (Service Level Indicator) est une mesure. C'est quelque chose que vous pouvez compter, comme « pourcentage de requêtes réussies » ou « combien de temps la page a mis à charger ». Si vous ne pouvez pas le mesurer de façon fiable, ce n'est pas un bon SLI.
Un SLO (Service Level Objective) est l'objectif pour cette mesure. Il répond à : quel niveau est suffisant pour les utilisateurs la plupart du temps ? Les SLO aident à décider quoi corriger en premier et ce qui peut attendre.
Un SLA (Service Level Agreement) est une promesse, généralement écrite, souvent avec des conséquences. Beaucoup d'outils internes n'ont pas besoin d'SLA. Ils ont besoin d'objectifs clairs, pas d'engagements de type contractuel.
Un exemple rapide :
Remarquez ce qui manque : « jamais en panne » ou « toujours rapide ». Les SLO ne visent pas la perfection. Ils rendent les compromis visibles pour qu'une petite équipe puisse choisir entre fonctionnalités, travail de fiabilité et éviter l'usure inutile.
Une règle pratique : si atteindre la cible nécessite des interventions héroïques, ce n'est pas un SLO, c'est un vœu pieux. Commencez par quelque chose que votre équipe peut maintenir calmement, puis resserrez ensuite si les utilisateurs ressentent encore une douleur.
Les outils internes échouent de façons spécifiques : le panneau admin charge mais l'enregistrement reste en attente ; un tableau ops s'ouvre mais les graphiques ne se rafraîchissent jamais ; un portail fonctionne sauf que la connexion se casse après une mise à jour. Vous tirez le plus de valeur en vous concentrant sur les actions quotidiennes dont les gens dépendent, pas sur chaque page et bouton.
Commencez par nommer le type d'outil, car cela indique les chemins critiques. Les panneaux admin sont axés sur « modifier quelque chose en toute sécurité ». Les tableaux ops servent à « voir ce qui se passe maintenant ». Les portails servent à « entrer, trouver l'info et soumettre une demande ».
Ensuite écrivez les principaux parcours utilisateurs en langage clair. Un bon ensemble de départ :
Pour chaque parcours, définissez ce qui compte comme échec. Soyez strict et mesurable : une erreur 500 est un échec, tout comme un timeout, une page qui ne finit jamais de charger, ou un formulaire qui indique succès alors que les données sont manquantes.
Gardez la portée petite au départ. Choisissez 1 à 3 parcours qui correspondent à une vraie douleur et à un vrai risque. Si les pages d'astreinte courantes sont « personne ne peut se connecter » et « le bouton sauvegarder bloque », commencez par Connexion et Soumission de formulaire. Ajoutez Recherche plus tard une fois que vous faites confiance aux mesures et aux alertes.
Les bons SLIs sont ennuyeux. Ils proviennent des données que vous avez déjà et correspondent à ce que ressent l'utilisateur quand l'outil marche ou échoue. Si vous devez construire tout un système de monitoring juste pour les mesurer, choisissez des SLIs plus simples.
Commencez par la disponibilité en termes compréhensibles : est-ce que je peux ouvrir l'outil et mener la tâche à bien ? Pour beaucoup d'outils internes, deux SLIs couvrent la majorité des problèmes :
Ajoutez ensuite la latence, mais restez étroit. Choisissez un ou deux écrans ou endpoints qui représentent l'attente dont les utilisateurs se plaignent, comme le chargement du tableau de bord ou la soumission d'un formulaire. Mesurer tout crée généralement du bruit et des disputes.
Décidez de la fenêtre de mesure dès le départ. Une fenêtre glissante de 30 jours est courante pour les outils stables ; la semaine peut convenir si vous déployez souvent et voulez un retour rapide. Quel que soit votre choix, tenez-vous y afin que les tendances aient du sens.
Enfin, choisissez une source de vérité par SLI et consignez-la :
Exemple : si votre app interne est construite sur AppMaster, vous pouvez mesurer la disponibilité par un ping synthétique au backend, le taux de succès via les réponses API, et la latence via le timing des requêtes backend. L'important est la cohérence, pas la perfection.
Commencez par choisir un chiffre de disponibilité que vous pouvez défendre même une mauvaise semaine. Pour beaucoup d'outils internes, 99,5 % est un bon premier SLO. Ça semble élevé, mais laisse de la marge pour le travail normal de changement. Passer directement à 99,9 % signifie souvent des pages en dehors des heures et des releases plus lentes.
Pour rendre la disponibilité concrète, traduisez-la en temps. Un mois de 30 jours compte environ 43 200 minutes :
Ce temps permis est votre budget d'erreur. Si vous le consommez tôt, vous interrompez les changements risqués et vous concentrez sur la fiabilité jusqu'à revenir dans les clous.
Pour la latence, évitez les moyennes. Elles cachent les moments lents dont les utilisateurs se souviennent. Utilisez un percentile (généralement p95) et fixez un seuil clair lié à une action réelle. Exemples : « p95 chargement du tableau de bord < 2 secondes » ou « p95 Sauvegarde < 800 ms ».
Une façon simple de fixer la première valeur est d'observer une semaine de trafic réel, puis de choisir un objectif légèrement meilleur qu'aujourd'hui mais pas fantaisiste. Si le p95 est déjà 1,9 s, un SLO à 2,0 s est sûr et utile. Un SLO à 500 ms ne fera que créer du bruit.
Adaptez les SLO à votre capacité de support. Une petite équipe préfère quelques objectifs atteignables plutôt que beaucoup d'objectifs stricts. Si personne ne peut répondre en une heure, ne fixez pas d'objectifs qui supposent une intervention dans l'heure.
Un SLO plus strict rassure, mais il a un coût. Si vous passez un outil de 99,5 % à 99,9 %, vous dites aussi « nous acceptons beaucoup moins de minutes mauvaises », ce qui signifie généralement plus de pages et plus de temps consacré à la fiabilité au détriment des nouvelles fonctionnalités.
La manière la plus simple de rendre cela concret est de parler en terme de budget d'erreur. Avec un objectif de 99,5 % mensuel, vous pouvez « dépenser » environ 3,6 heures d'indisponibilité sur 30 jours. Avec 99,9 %, vous n'avez qu'environ 43 minutes. Cette différence change la fréquence à laquelle vous interromprez le travail fonctionnel pour réparer la fiabilité.
Il aide aussi d'adapter les attentes aux moments où l'outil est vraiment utilisé. Une cible 24/7 coûte cher si l'outil n'est critique que de 9h à 18h. Vous pouvez définir un SLO plus strict pendant les heures ouvrables et un plus souple hors heures pour que l'équipe puisse dormir.
La maintenance planifiée ne doit pas compter comme échec tant qu'elle est communiquée et limitée. Traitez-la comme une exception explicite (fenêtre de maintenance) plutôt que d'ignorer les alertes après coup.
Consignez les bases pour que tout le monde voie les compromis :
Après 4 à 6 semaines de données réelles, revoyez l'objectif. Si vous ne consommez jamais de budget d'erreur, le SLO est peut-être trop lâche. Si vous l'épuisez rapidement et que les fonctionnalités stagnent, il est probablement trop strict.
Les alertes ne sont pas les SLO. Les alertes sont le signal « quelque chose ne va pas maintenant » qui protège le SLO. Une règle simple : pour chaque SLO, créez une alerte qui compte, et résistez à en ajouter sauf si vous pouvez prouver qu'elles réduisent le temps d'indisponibilité.
Une approche pratique est d'alerter sur une consommation rapide du budget d'erreur (SLO burn) ou sur un seuil clair qui correspond à la douleur utilisateur. Si votre SLO de latence est « p95 < 800 ms », ne pagez pas à chaque pic lent. Pagez seulement quand c'est soutenu.
Une séparation simple qui réduit le bruit :
Seuils concrets (à ajuster selon votre trafic) : si votre SLO de disponibilité est 99,5 % mensuel, pagez quand la disponibilité descend sous 99 % pendant 10 minutes (panne claire). Créez un ticket quand elle descend sous 99,4 % sur 6 heures (consommation lente). Pour la latence, pagez quand le p95 dépasse 1,5 s pendant 15 minutes ; créez un ticket quand le p95 dépasse 1,0 s pendant 2 heures.
Rendez la responsabilité explicite. Décidez qui est d'astreinte (même si c'est « une personne cette semaine »), ce que signifie acquitter (par ex. répondre sous 10 minutes), et la première action. Pour une petite équipe exécutant une app interne construite sur AppMaster, la première action peut être : vérifier les déploiements récents, regarder les erreurs API, puis effectuer un rollback ou redéployer si nécessaire.
Après chaque alerte réelle, faites un petit suivi : corrigez la cause ou ajustez l'alerte pour qu'elle page moins souvent mais capture toujours l'impact utilisateur réel.
La fatigue d'alerte commence souvent avec de bonnes intentions. Une petite équipe ajoute « juste quelques » alertes, puis une de plus chaque semaine. Bientôt, les gens cessent de faire confiance aux notifications et de vraies pannes sont manquées.
Un gros piège est d'alerter sur chaque pic. Les outils internes ont souvent un trafic en rafales (runs de paie, rapports de fin de mois). Si une alerte se déclenche sur un pic de 2 minutes, l'équipe apprend à l'ignorer. Liez les alertes à des signaux d'impact utilisateur, pas au bruit des métriques brutes.
Un autre piège est de penser « plus de métriques = plus sûr ». Le plus souvent c'est plus de pages. Tenez-vous à un petit ensemble de signaux ressentis par les utilisateurs : échec de connexion, pages trop lentes, jobs clés qui ne se terminent pas.
Les erreurs qui génèrent le plus de bruit :
Les dashboards restent importants, mais ils doivent aider au diagnostic après une alerte, pas remplacer l'alerte.
Si vous n'avez pas encore de mesures propres, ne faites pas semblant. Ajoutez d'abord l'instrumentation de base (taux de succès, latence p95, et une vérification « l'utilisateur peut accomplir la tâche »), puis fixez des seuils sur une ou deux semaines de données réelles.
Avant d'activer les alertes, faites une pré-vérification courte. La plupart des fatigues d'alerte viennent du fait d'avoir sauté une de ces étapes, puis d'essayer de réparer sous pression.
Une checklist pratique pour une petite équipe :
Ensuite, assurez-vous que l'alerte est vraiment actionnable. Une alerte qui se déclenche quand personne n'est dispo habitue les gens à l'ignorer.
Décidez ces détails opérationnels avant la première page :
Si vous construisez ou changez l'outil (y compris dans AppMaster), refaites la checklist. Le code régénéré et les nouveaux flux peuvent changer la latence et les erreurs, et vos alertes doivent suivre.
Une équipe ops de 18 personnes utilise un tableau de bord interne toute la journée pour vérifier l'état des commandes, renvoyer les notifications échouées et approuver des remboursements. Si c'est en panne ou lent, le travail stoppe vite.
Ils choisissent deux SLO :
Puis ils ajoutent trois alertes qu'une petite équipe peut gérer :
Ce qui compte, c'est ce qui se passe la semaine suivante. Si l'alerte de budget d'erreur s'est déclenchée deux fois, l'équipe prend une décision claire : retarder une nouvelle fonctionnalité et passer deux jours à corriger la principale cause de latence (par ex. un scan de table sans index). Si l'outil est construit dans AppMaster, ils peuvent ajuster le modèle de données, régénérer et redéployer du code propre au lieu d'empiler des rustines.
Les SLO n'aident que s'ils restent connectés au travail réel. L'astuce est de les traiter comme une petite habitude, pas un nouveau programme.
Adoptez un rythme adapté à une petite équipe et rattachez-le à une réunion existante. Un coup d'œil hebdomadaire rapide détecte les dérives, et un ajustement mensuel suffit une fois que vous avez des données réelles.
Un processus léger qui tient :
Gardez les améliorations petites et visibles. Si « pages lentes tous les lundis matin » revient trois fois, faites un changement concret (cacher un rapport, ajouter un index, déplacer un job lourd), puis surveillez le SLI la semaine suivante.
Utilisez les SLO pour dire non, poliment et clairement. Lorsqu'une demande pour une fonctionnalité de faible valeur arrive, montrez le budget d'erreur actuel et demandez : « Ce changement mettra-t-il en risque notre flux de sauvegarde ou d'approbation ? » Si vous consommez déjà le budget, la fiabilité gagne. Ce n'est pas bloquer, c'est prioriser.
Conservez une documentation minimale : une page par outil. Incluez les actions clés, les chiffres SLO, les quelques alertes associées et le propriétaire. Si l'outil est construit sur AppMaster, ajoutez où voir logs/métriques et qui peut déployer, puis stoppez.
La façon la plus simple de rendre la fiabilité réelle est de garder la première configuration minime. Choisissez un outil interne qui cause une vraie douleur quand il casse (passage d'astreinte, approbation de commandes, remboursements, modifications d'inventaire), et définissez des objectifs autour des quelques actions quotidiennes.
Une configuration minimale pratique que la plupart des équipes peuvent copier :
Une fois stable, étendez lentement : ajoutez une action de plus, ou un outil de plus par mois. Si vous ne pouvez pas dire qui possédera une alerte, ne la créez pas encore.
Si vous construisez ou reconcevez des outils internes, AppMaster peut faciliter la maintenance. Vous pouvez mettre à jour les modèles de données et la logique métier visuellement et régénérer du code propre quand les besoins changent, ce qui aide à garder les SLO alignés avec ce que l'outil fait réellement aujourd'hui.
Essayez de construire un outil interne et d'ajouter des SLO basiques dès le premier jour. Vous obtiendrez des attentes plus claires, moins de surprises et des alertes que votre petite équipe pourra suivre.
Les outils internes ont-ils vraiment besoin de SLO si seuls quelques employés les utilisent ?Les SLO mettent fin aux discussions sur la fiabilité en transformant « assez stable » en un objectif clair et mesurable. Même avec 20 utilisateurs, une panne peut stopper des commandes, ralentir le support ou bloquer des validations — les petits outils peuvent donc avoir un impact important.
Que devrions-nous mesurer en premier pour un panneau d'administration ou un tableau ops interne ?Choisissez quelques actions utilisateur que l'on fait chaque jour et qui bloquent le travail en cas d'échec. Les points de départ courants : connexion, chargement du tableau de bord principal avec des données fraîches, recherche/filtrage, et soumission réussie d'un formulaire de création/mise à jour.
Quelle est la différence entre un SLI, un SLO et un SLA ?Un SLI est la métrique (par exemple taux de succès ou latence p95). Un SLO est l'objectif pour cette métrique (par exemple 99,5 % de succès sur 30 jours). Un SLA est un engagement formel avec des conséquences ; la plupart des outils internes n'en ont pas besoin.
Quel est un SLO de disponibilité réaliste pour une petite équipe ?Un bon premier SLO de disponibilité pour beaucoup d'outils internes est 99,5 % par mois, car il est atteignable sans actions héroïques constantes. Si l'outil est vraiment critique pendant les heures de travail, vous pourrez le resserrer après avoir vu des données réelles.
Comment traduire les pourcentages de disponibilité en temps d'indisponibilité compréhensible ?Transformez le pourcentage en minutes pour que tout le monde comprenne l'arbitrage. Sur un mois de 30 jours, 99,5 % laisse environ 216 minutes d'indisponibilité, tandis que 99,9 % laisse environ 43 minutes — ce qui implique souvent plus de pages et plus de travail de fiabilité.
Comment définir des SLO de latence sans créer de bruit ?Utilisez un percentile comme le p95, pas une moyenne, car les moyennes cachent les moments lents que les utilisateurs ressentent. Fixez la cible sur une action réelle (par ex. « p95 chargement du tableau de bord < 2s pendant les heures ouvrables ») et choisissez un seuil que vous pouvez maintenir calmement.
Quelles SLIs sont les plus faciles à mesurer sans construire un gros système de monitoring ?Commencez par les métriques serveur et les logs que vous avez déjà : disponibilité (accessible et répond), taux de réussite pour les actions clés, et latence p95 pour un ou deux endpoints/écrans critiques. Ajoutez des vérifications synthétiques seulement pour les flux les plus importants afin de garder les mesures cohérentes et simples.
Combien d'alertes devrions-nous configurer pour un outil interne ?Limitez-vous à un petit ensemble d'alertes liées à l'impact utilisateur, et avertissez seulement sur des problèmes soutenus. Une séparation utile : une page urgente pour « l'outil est effectivement cassé » et un ticket non urgent pour la dégradation lente que l'on peut traiter pendant les heures de travail.
Qu'est-ce qui cause la fatigue d'alerte pour les outils internes et comment l'éviter ?La plupart des fatigues d'alerte viennent d'alerter sur chaque pic ou sur des symptômes (CPU, mémoire) plutôt que sur l'impact utilisateur (erreurs, latence). Gardez peu d'alertes, donnez un propriétaire à chacune, et après chaque alerte réelle, corrigez la cause ou ajustez l'alerte pour réduire les fausses alertes.
Comment appliquer des SLO si nous construisons nos outils internes dans AppMaster ?Identifiez les actions clés dans votre application, puis mesurez la disponibilité, le taux de succès et la latence p95 pour ces actions en utilisant une source de vérité cohérente. Si vous construisez des outils internes dans AppMaster (appmaster.io), concentrez les objectifs sur ce que font les utilisateurs (login, sauvegarde, recherche) et ajustez mesures et alertes après des changements majeurs ou des régénérations.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
