Utilisez ce runbook d'incident pour applications no-code afin de détecter vite les problèmes, trier l'impact, rollbacker en sécurité, communiquer clairement et prévenir les répétitions.
Un incident est tout problème inattendu qui empêche des personnes d’utiliser votre application, la rend douloureusement lente ou met des données en danger. Dans les apps no-code, cela peut se traduire par des échecs de connexion soudains, des écrans cassés après un changement, des automatisations en arrière-plan qui cessent de s’exécuter, des erreurs d’API, ou des flux « réussis » qui écrivent silencieusement de mauvaises valeurs en base.
Un runbook écrit transforme un moment stressant en une série d’actions petites et claires. Il réduit les hésitations, accélère les décisions (comme savoir quand rollbacker) et aide tout le monde à partager les mêmes faits. La plupart des retards pendant les incidents ne sont pas techniques. Ils viennent de l’incertitude : est-ce réel ? Qui mène ? Qu’est-ce qui a changé ? Que dire aux utilisateurs ?
Ce playbook s’adresse à toute personne touchant l’app quand ça va mal : les builders qui publient des changements, les responsables ops ou plateforme qui gèrent les déploiements et les accès, les équipes support qui reçoivent les premiers signalements, et les responsables produit ou business qui évaluent l’impact et les priorités.
Il est volontairement léger, y compris pour les équipes qui construisent sur des plateformes comme AppMaster où vous pouvez avoir de la logique visuelle, des services générés et plusieurs options de déploiement.
Il couvre la boucle complète d’un incident : détecter et confirmer un vrai problème, trier rapidement, stabiliser et récupérer (y compris décisions de rollback), communiquer pendant la panne, puis faire une courte revue post-incident pour réduire les risques de répétition.
Il ne couvre pas la refonte d’architecture à long terme, les forensiques de sécurité approfondies, ni les procédures de conformité complexes. Si vous traitez des données régulées ou des infrastructures critiques, ajoutez des étapes plus strictes en complément de ce runbook.
Les incidents semblent chaotiques quand vous ne savez pas à quoi ressemble le « normal ». Définissez votre baseline pour que l’équipe repère les vrais problèmes rapidement. Pour une app no-code, les signaux initiaux viennent souvent d’un mélange de santé de la plateforme, métriques business et retours humains.
Écrivez les signaux que vous surveillerez au quotidien, pas seulement lors des pannes. Les plus communs : uptime, taux d’erreur, écrans lents, échecs de connexion, paiements ratés, et pics de tickets support ou messages utilisateurs.
Définissez la sévérité en langage clair pour que tout le monde puisse l’utiliser :
Fixez des objectifs de réponse qui créent de l’élan. Exemples : accuser réception en 5 minutes, poster la première mise à jour en 15 minutes, et viser à stabiliser en 60 minutes (même si la correction complète prend plus de temps).
Décidez des rôles avant d’en avoir besoin. Nommez qui peut déclarer un incident, qui le dirige, et qui est le backup si cette personne est hors ligne. Dans les équipes AppMaster, c’est souvent la personne qui possède la logique Business Process, plus un backup qui peut gérer les déploiements ou les exports.
Enfin, gardez un endroit partagé pour les notes d’incident. Utilisez des horodatages pour chaque action (quoi, quand, par qui) pour reconstruire l’histoire plus tard sans deviner.
Confirmez l’impact avant de fixer les yeux sur les dashboards. Posez une question claire : qui ne peut pas faire quoi maintenant ? « L’équipe support ne peut pas ouvrir de tickets » est plus utile que « l’app est lente ». Si possible, reproduisez le problème avec le même rôle et appareil que l’utilisateur affecté.
Ensuite, évaluez l’étendue. Est-ce un seul compte, un segment de clients ou tout le monde ? Faites des divisions rapides : région, type de compte, web vs mobile, fonctionnalité unique vs toute l’app. Dans les outils no-code, quelque chose peut sembler global alors qu’il s’agit d’une règle de permission ou d’un écran cassé.
Puis vérifiez ce qui a changé. Regardez 1–2 heures en arrière pour une release, un toggle de config, une édition de schéma de base de données ou une importation de données. Sur des plateformes comme AppMaster, des changements aux Business Processes, modèles de données ou paramètres d’auth peuvent affecter de nombreux flux d’un coup, même si l’UI semble correcte.
Avant d’accuser votre application, écartez les dépendances externes. Fournisseurs d’email/SMS, paiements (par exemple Stripe) et intégrations (Telegram, services AWS, APIs d’IA) peuvent tomber en panne ou limiter les requêtes. Si l’app casse uniquement lors d’envois de messages ou de prélèvements, la racine peut être en amont.
Utilisez une checklist de décision simple :
Une fois la sévérité et la portée classifiées, vous pouvez passer de « est-ce réel ? » à « que fait-on d’abord ? » sans deviner.
Ouvrez immédiatement un enregistrement d’incident. Donnez-lui un titre clair qui nomme l’impact utilisateur, pas la cause supposée (par exemple « Paiement échoue pour clients EU »). Notez l’heure de début (première alerte ou premier signalement). Ce document devient le lieu unique pour décisions, horodatages et changements.
Assignez des rôles pour éviter les recouvrements. Même dans une petite équipe, nommer des propriétaires réduit les erreurs sous stress. Au minimum, vous voulez :
Écrivez deux choses : ce que vous savez avec certitude, et votre hypothèse courante. « Connu » peut être : le taux d’erreur a grimpé, un endpoint spécifique échoue, seul le mobile est affecté. L’hypothèse peut être fausse, mais elle doit guider le test suivant. Mettez à jour les deux au fur et à mesure que vous en apprenez davantage.
Pendant l’instabilité, définissez un rythme de mise à jour toutes les 15 minutes. Si rien n’a changé, dites-le. Les mises à jour régulières arrêtent les discussions parallèles et préviennent les messages redondants « des nouvelles ? ».
Choisissez la première action de contention. L’objectif est de réduire le dommage rapidement, même si la cause racine n’est pas claire. Mouvements typiques : mettre en pause des jobs en arrière-plan, désactiver un feature flag risqué, limiter le trafic vers un module, ou basculer sur une configuration connue sûre. Sur AppMaster, cela signifie souvent couper un flow spécifique dans le Business Process Editor ou masquer temporairement un chemin UI qui déclenche les erreurs.
Si la contention n’améliore pas les métriques dans une fenêtre de cadence, commencez en parallèle la planification du rollback.
Une fois confirmé incident réel, passez de « trouver le bug » à « arrêter l’hémorragie ». Stabiliser vous achète du temps. Cela protège aussi les utilisateurs, le revenu et les données pendant l’investigation.
Commencez par le plus petit changement qui réduit le dommage. La contention est souvent plus rapide qu’un correctif complet car vous pouvez désactiver une nouvelle fonctionnalité, arrêter un workflow ou bloquer un chemin d’entrée risqué sans reconstruire.
Si vous suspectez une corruption de données, stoppez d’abord les écritures. Cela peut signifier désactiver temporairement des formulaires, mettre en pause des automatisations qui mettent à jour des enregistrements, ou bloquer un endpoint API acceptant des mises à jour. Lire de mauvaises données fait mal, mais écrire de mauvaises données multiplie le nettoyage.
Si les utilisateurs sont verrouillés hors de l’app, traitez la connexion comme la priorité numéro un. Vérifiez les paramètres d’authentification et le flux de login avant tout. Les autres correctifs sont plus lents si les utilisateurs (et votre équipe) ne peuvent pas accéder à l’app.
Si l’app est lente ou time-out, réduisez la charge et retirez les chemins coûteux. Désactivez les écrans lourds, mettez en pause les jobs en batch, et désactivez les nouvelles intégrations qui provoquent des pics de requêtes. Dans AppMaster, la contention peut se résumer à désactiver un Business Process problématique ou supprimer temporairement une action UI qui déclenche une chaîne coûteuse.
Gardez les actions délibérées et documentées. Sous pression, les équipes répètent des étapes ou annulent un correctif par accident. Notez chaque changement et le résultat.
Séquence de stabilisation simple :
Vous visez « sûr et utilisable », pas « entièrement résolu ». Une fois l’impact contenu, vous pouvez diagnostiquer calmement et choisir le rollback ou correctif adapté.
Quand quelque chose casse, la vitesse compte, mais le mouvement le plus sûr gagne. Vous avez en pratique trois options : rollback, livrer un correctif en avant, ou faire un revert partiel (désactiver une fonctionnalité tout en laissant le reste).
D’abord, soyez clair sur ce que « rollback » signifie dans votre configuration. Cela peut être déployer la version précédente de l’app, revenir sur un changement de config, ou restaurer un état de base de données. Sur des plateformes comme AppMaster, une « version » peut inclure la logique backend, l’UI web, les builds mobiles et les paramètres d’environnement.
Utilisez ces vérifications de risque pour décider si le rollback est sûr :
Fixez une règle go/no-go simple avant d’agir. Choisissez 2–3 métriques qui doivent s’améliorer sous 10–15 minutes après l’action, par exemple taux d’erreur, succès de connexion, finalisation de checkout ou latence d’API. Si elles ne bougent pas dans le bon sens, arrêtez et changez de stratégie.
Planifiez aussi le backout du rollback. Sachez comment vous l’annulerez si l’ancienne version cause de nouveaux problèmes : quelle build redéployer, quelle config réappliquer et qui approuve ce second changement. Gardez une personne responsable de la décision finale de « ship » pour ne pas changer de cap en cours d’étape.
Le silence aggrave les incidents. Utilisez une méthode simple et répétable pour tenir les gens informés pendant l’investigation.
Commencez par des updates internes. Informez les personnes qui recevront les questions en premier, et celles qui peuvent lever les blocages. Restez bref et factuel. Vous aurez typiquement besoin de :
Pour les messages externes, tenez-vous à ce que vous savez. Évitez de supposer la cause ou de blâmer un fournisseur. Les utilisateurs veulent surtout trois choses : confirmation, impact et quand vous les tiendrez au courant.
Gardez une ligne de statut cohérente sur tous les canaux :
Si les utilisateurs sont en colère, reconnaissez d’abord, puis soyez précis : « Nous savons que le checkout échoue pour certains clients. Nous rollbackons le dernier changement maintenant. Prochaine mise à jour dans 30 minutes. » Ne promettez pas de délais fermes, de crédits ou de correctifs définitifs pendant l’incident.
Déclarez résolu seulement lorsque le symptôme principal a disparu et que les contrôles clés sont propres (logins, flux cœur, taux d’erreur). Utilisez monitoring lorsque vous avez appliqué un correctif (par exemple rollback ou restauration de config) mais devez encore surveiller les répétitions. Indiquez toujours ce que vous surveillerez, pendant combien de temps, et quand le message final sera publié.
Une fois stable, passez de la lutte contre le feu à la collecte du plus petit ensemble de faits qui explique les symptômes. L’objectif n’est pas un root cause parfait, mais une cause probable sur laquelle agir sans empirer l’incident.
Différents symptômes pointent vers différents coupables. Des pages lentes signifient souvent des requêtes DB lentes, un pic de trafic, ou un service externe qui répond mal. Des timeouts peuvent venir d’un processus bloqué, d’un backend surchargé, ou d’une intégration qui attend trop longtemps. Un pic d’erreurs ou de retries renvoie souvent à un changement récent, une mauvaise entrée, ou une panne en amont.
Exécutez un parcours utilisateur réel de bout en bout avec un compte test normal. C’est souvent le signal le plus rapide car il touche UI, logique, base de données et intégrations.
Concentrez-vous sur quelques contrôles :
Sur AppMaster, cela correspond souvent à un step Business Process, un changement Data Designer, ou une config de déploiement.
Si les vérifications rapides pointent un coupable clair, choisissez le mouvement le plus sûr : maintenir la mitigation en place ou appliquer un petit correctif permanent. N’enlevez les limites de débit, feature toggles ou contournements manuels qu’après que le parcours ait réussi deux fois et que le taux d’erreur reste stable quelques minutes.
Il est 10:15 un mardi. Une équipe publie un petit changement sur un portail client construit sur AppMaster. En quelques minutes, les utilisateurs voient des pages vides après connexion et les nouvelles commandes n’arrivent plus.
Le support reçoit trois tickets identiques : « La connexion marche, puis le portail ne charge plus. » En parallèle, la surveillance montre un pic d’erreurs 500 sur l’app web et une baisse des appels API réussis. Vous le traitez comme un incident réel.
Le responsable d’incident fait une confirmation rapide : essayer de se connecter en tant qu’utilisateur test sur desktop et mobile, vérifier l’heure du dernier déploiement. Le timing correspond à la release, donc vous supposez que le dernier changement est impliqué jusqu’à preuve du contraire.
Les 30 premières minutes peuvent ressembler à ceci :
À 10:40, les erreurs reviennent à la normale. Vous gardez un œil sur les métriques pendant que le support confirme une baisse des nouveaux tickets.
Ensuite, l’équipe fait une courte revue : qu’est-ce qui a détecté le problème en premier (alertes vs support), ce qui a ralenti la résolution (propriétaire manquant, étapes de rollback peu claires), et ce qu’il faut changer. Une amélioration courante : ajouter une checklist smoke-test de release pour les trois parcours principaux du portail et rendre le rollback une action documentée et simple.
La plupart des incidents empirent pour deux raisons : on laisse le système faire du mal pendant qu’on enquête, ou on change trop de choses trop vite. Ce runbook vise à vous protéger des deux.
Un piège fréquent : enquêter pendant que l’app continue d’écrire de mauvaises données. Si un workflow boucle, une intégration poste des doublons, ou un bug de permission permet à de mauvais utilisateurs d’éditer des enregistrements, mettez d’abord le processus en pause. Dans AppMaster, cela peut vouloir dire désactiver un Business Process, couper une intégration module, ou restreindre temporairement l’accès.
Un autre piège : « réparer » en devinant. Quand plusieurs personnes cliquent partout et changent des réglages, vous perdez la timeline. Même de petites modifications comptent pendant un incident. Choisissez un pilote, tenez un journal simple, et évitez d’empiler des ajustements sur des inconnues.
Erreurs récurrentes qui allongent les pannes :
La communication fait partie de la récupération. Partagez ce que vous savez, ce que vous ne savez pas, et quand aura lieu la prochaine mise à jour. « Nous rollbackons et confirmerons les événements de facturation corrects dans 15 minutes » vaut mieux que « On regarde. »
Ne fermez pas l’incident juste parce que les erreurs ont cessé. Vérifiez avec une checklist courte : les écrans clés chargent, les nouveaux enregistrements se sauvegardent correctement, les automatisations critiques s’exécutent au moins une fois, et les backlogs (queues, retries, jobs planifiés) sont vidés ou mis en pause en sécurité.
Quand ça casse, votre cerveau va vouloir faire dix choses à la fois. Utilisez ceci pour rester calme, protéger les gens et rétablir le service.
Épinglez cette section là où votre équipe la verra réellement.
Prenez une minute pour nommer un propriétaire d’incident. Une personne décide, les autres assistent.
Stabiliser et contenir (10 minutes) : Arrêtez l’hémorragie avant de chercher la cause. Désactivez le chemin risqué (feature toggle, bannière temporaire, pause des queues) et testez un parcours clé de bout en bout. Choisissez le parcours qui compte le plus pour le business, pas forcément le plus simple à tester.
Récupérer le service (10–20 minutes) : Choisissez le mouvement le plus sûr : rollback à la dernière version connue bonne ou appliquer un correctif minimal. Sur des plateformes comme AppMaster, cela peut être redéployer une build précédente ou revenir sur le dernier changement, puis confirmer le retour à la normale des taux d’erreur et temps de réponse.
Communiquer (en continu) : Publiez une courte mise à jour avec ce qui est impacté, ce que doivent faire les utilisateurs et l’heure de la prochaine mise à jour. Briefer le support avec un script en deux phrases pour que tout le monde dise la même chose.
Clore proprement (avant d’oublier) : Enregistrez ce qui s’est passé, ce que vous avez changé et l’heure de récupération. Assignez des actions de suivi avec un propriétaire et une date (tweak de monitoring, test manquant, nettoyage de données, correctif de suivi).
Un incident n’est pas « fini » quand l’app est de nouveau en ligne. Le moyen le plus rapide de réduire les futurs temps d’arrêt est de capturer ce qui s’est passé tant que c’est frais, puis de transformer ces apprentissages en petits changements réels.
Planifiez une courte revue post-incident sous 2–5 jours. Restez sans blâme et pratique. L’objectif n’est pas de trouver un coupable, mais de rendre le prochain incident plus facile à gérer.
Rédigez un rapport que quelqu’un pourra lire des mois plus tard : ce que voyaient les utilisateurs, quand vous l’avez détecté, ce que vous avez essayé, ce qui a marché, et quand le service est revenu. Incluez la cause racine si connue, et notez les facteurs contributifs comme des alertes manquantes, une propriété floue ou des étapes de déploiement confuses.
Transformez les apprentissages en tâches avec propriétaires et échéances. Concentrez-vous sur les plus petits changements qui empêchent la même panne :
Choisissez une mesure préventive par incident, même petite. « Toute modification des rôles nécessite un second relecteur » ou « Les migrations de données doivent d’abord s’exécuter dans une copie de staging » peuvent éviter des pannes répétées.
Gardez ce runbook à côté de votre process de build et release. Si vous construisez avec AppMaster, notez où chaque app est déployée (AppMaster Cloud, AWS, Azure, Google Cloud, ou self‑hosted), qui peut redéployer rapidement et qui peut rollbacker. Si vous voulez un endroit unique pour cette documentation, la garder proche des notes de projet AppMaster (appmaster.io) facilite l’accès quand les minutes comptent.
Quand devons-nous considérer un problème comme un incident pour une application no-code ?Utilisez-le dès qu’un problème inattendu bloque des tâches essentielles, rend l’application inutilisable ou risque de provoquer des écritures de données incorrectes ou dangereuses. Si les utilisateurs ne peuvent pas se connecter, si les paiements échouent, si les automatisations s’arrêtent ou si des enregistrements sont écrits de façon incorrecte, traitez-le comme un incident et suivez le runbook.
Quelle est la manière la plus rapide de confirmer qu’un incident est réel et de mesurer l’impact ?Commencez par l’impact utilisateur : qui ne peut pas faire quoi maintenant et depuis quand. Reproduisez ensuite le problème avec le même rôle et le même appareil, puis vérifiez s’il s’agit d’un seul compte, d’un segment ou de tous les utilisateurs afin de ne pas poursuivre la mauvaise piste.
Comment décider rapidement SEV1 vs SEV2 vs SEV3 ?Déclarez SEV1 lorsque la plupart des utilisateurs sont bloqués ou qu’il y a un risque pour l’argent, la sécurité ou les données. Utilisez SEV2 quand une fonctionnalité clé est cassée mais qu’il existe une solution de contournement, et SEV3 pour les problèmes mineurs ou à portée limitée ; décider vite est plus important qu’être parfait.
Qui doit faire quoi pendant un incident, surtout dans une petite équipe ?Désignez un incident lead qui prend les décisions finales, puis assignez un réparateur, un responsable comms et une personne qui prend les notes pour éviter les chevauchements ou les modifications accidentelles. Dans une petite équipe, une personne peut cumuler deux rôles, mais le rôle de responsable d’incident doit rester clair.
À quoi ressemble la « contention » dans AppMaster ou des plateformes no-code similaires ?La contention vise à arrêter le dommage rapidement, même si la cause n’est pas encore claire. Sur AppMaster, cela signifie souvent désactiver un Business Process spécifique, masquer temporairement une action UI qui déclenche des erreurs, ou mettre en pause une automatisation qui boucle ou écrase des données.
Quand faut-il faire un rollback plutôt que déployer une correction vers l’avant ?Rollback si le problème a commencé juste après une release et que vous avez une version connue bonne qui restaure rapidement le service. Optez pour une correction vers l’avant seulement si vous pouvez faire un petit changement à faible risque et le vérifier vite sans risquer plus de downtime.
Qu’est-ce qui rend un rollback dangereux dans des applications no-code ?Considérez le rollback risqué si le schéma de la base de données a changé, si des écritures irréversibles ont eu lieu, ou si des jobs en file d’attente et des webhooks pourraient être retraités par l’ancienne logique. Si c’est le cas, stabilisez d’abord et confirmez ce que l’ancienne version attend avant de la redéployer.
Si nous suspectons une corruption de données, que devons-nous faire en premier ?Stoppez d’abord les écritures si vous suspectez une corruption des données, car de mauvaises écritures multiplient le travail de nettoyage. Concrètement, désactivez les formulaires, mettez en pause les automatisations qui mettent à jour les enregistrements, ou bloquez les endpoints de mise à jour jusqu’à ce que vous puissiez confirmer qu’aucun nouvel enregistrement n’est modifié incorrectement.
Que devons-nous dire pendant une panne, et à quelle fréquence devons-nous mettre à jour ?Envoyez des mises à jour courtes et factuelles à intervalles réguliers avec ce qui est impacté, ce que vous faites et quand aura lieu la prochaine mise à jour. Évitez de deviner la cause ou d’accuser un fournisseur ; les utilisateurs et parties prenantes ont surtout besoin de clarté et de prévisibilité.
Quand est-il acceptable d’appeler un incident « résolu » plutôt que « en surveillance » ?Considérez l’incident « résolu » seulement lorsque le symptôme principal a disparu et que les contrôles clés sont propres (connexion, flux principal, taux d’erreur). Si vous avez appliqué un correctif mais devez encore surveiller les répétitions, choisissez « monitoring » en indiquant ce que vous surveillez et pendant combien de temps.
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é.
