Version : 1.0 — 28/07/2026
Public : Support N1 (aucun accès cluster requis)
Principe : chaque fiche = vérifications autorisées → résolution N1 si possible → escalade qualifiée avec les informations collectées.
| Outil |
Usage |
| Navigateur |
Tester les URLs de service, vérifier les messages d'erreur exacts |
| support.rber.bj |
Création, qualification, traçage des tickets |
| Plateforme de monitoring (compte lecture seule) |
Vérifier l'état global des services — grafana.rber.bj |
ping / nslookup / curl -I depuis poste |
Vérifier résolution DNS et réponse HTTP |
| Groupe Telegram alertes |
Vérifier si une alerte automatique correspond au signalement |
Interdit au N1 : kubectl, SSH bastion, Rancher, consoles d'administration des services.
Toute escalade sans ces éléments sera renvoyée :
- URL exacte concernée et heure précise du problème
- Message d'erreur exact (capture d'écran)
- Code HTTP si visible (503, 502, 404, 401…)
- Périmètre : un utilisateur / plusieurs / tous ? une université / toutes ?
- Test croisé : le problème existe-t-il depuis un autre réseau (4G vs campus) ?
- Alerte Telegram correspondante : oui/non, laquelle
Symptômes : page de connexion refuse les identifiants, ou boucle de redirection, ou erreur après saisie du mot de passe.
Vérifications N1 :
- Ouvrir https://auth.rber.bj — la page répond-elle ?
- Non (timeout, 502/503) → P1, escalade immédiate N2 (fiche R-02). Le SSO porte tout l'écosystème.
- Oui → continuer.
- Le problème touche-t-il un seul utilisateur ?
- Oui → cas compte : vérifier avec l'utilisateur l'identifiant exact (les comptes viennent du LDAP de son université — UAC, UNSTIM, UNA, UP). Faire tester « mot de passe oublié » si le flux existe. Si l'utilisateur vient d'être créé côté université : la synchronisation LDAP peut prendre du temps → ticket P3 vers N2.
- Plusieurs utilisateurs d'une même université → probable panne du LDAP de l'université (serveur chez l'université, pas chez RBER) → ticket P2, escalade N2 en précisant l'université.
- Boucle de redirection entre le service (ex. Moodle) et auth.rber.bj → P2 N2 avec capture de l'URL complète au moment de la boucle.
Résolution N1 possible : erreurs de saisie, mauvais identifiant, majuscules, compte non encore créé côté université.
Symptômes : page blanche, 503, 502, timeout.
Vérifications N1 :
nslookup <url> — la résolution DNS répond-elle ? Non → ticket P2 N2 « résolution DNS KO ».curl -I https://<url> ou navigateur — noter le code HTTP exact.- Tester 2 autres services (ex. git.rber.bj, auth.rber.bj) :
- Tous down → P1, escalade directe N3 (suspicion incident infrastructure — précédent du 23/07/2026 : switch stockage). Ne pas multiplier les tickets : un seul ticket incident majeur.
- Un seul service down → escalade N2 avec code HTTP.
- Vérifier le groupe Telegram : une alerte correspond-elle ? La citer dans le ticket.
503 sur elearning.unstim.bj = P1 systématique (~200 000 étudiants concernés à terme).
Vérifications N1 :
- Webmail (RENSEIGNER_URL_WEBMAIL) répond-il ? Non → P2 N2.
- Un seul utilisateur ou tous ?
- Un seul, envoi vers l'extérieur refusé → collecter le message d'erreur SMTP exact (code 4xx/5xx) → N2.
- Un seul, connexion refusée → possible bannissement fail2ban après erreurs de mot de passe → demander depuis quelle IP/réseau il se connecte → N2 (déban runbook mail §6).
- Mails vers Gmail/Outlook arrivent en spam → ticket P3 N2 « délivrabilité » (dossier SPF/DKIM/PTR).
- Aucun mail ne circule pour personne → P2 N2 immédiat.
Résolution N1 possible : configuration client mail erronée. Paramètres corrects à communiquer : IMAP mail.rber.bj:993 (SSL), SMTP mail.rber.bj:465 (SSL), identifiant = adresse complète.
Vérifications N1 :
- https://visio.rber.bj répond ? Non → P2 N2.
- Problème audio/vidéo d'un participant :
- Vérifier navigateur (Chrome/Firefox récents), autorisations micro/caméra, tester le test d'écho BBB.
- Réseau campus : la visio requiert UDP 16384–32768 — si un seul site est affecté, probable filtrage réseau local → orienter vers l'IT du campus.
- « Session pleine » ou lenteurs générales avec beaucoup de participants → collecter nombre de participants + heure → N2 (charge serveur).
Résolution N1 possible : 80 % des cas = navigateur/permissions/réseau local du participant.
Symptôme : avertissement navigateur « connexion non privée ».
- Noter l'URL exacte et la date d'expiration affichée dans les détails du certificat.
- → Ticket P2 N2. Aucune action N1.
- Quantifier : quelle page, combien de secondes, à quelle heure, combien d'utilisateurs.
- Tester depuis un autre réseau (4G) : lenteur identique ?
- Non → problème réseau campus → IT campus.
- Oui → ticket P3 N2 avec mesures.
¶ Fiche R-07 — Demande de compte / d'accès
| Demande |
Circuit |
| Compte étudiant/enseignant (SSO) |
Créé par l'université dans son LDAP — rediriger vers la scolarité/DSI de l'université. RBER ne crée pas ces comptes. |
| Compte Gitea/Harbor développeur |
Ticket P4 → N2 |
| Boîte mail @rber.bj |
Ticket P4 → N2 (validation selon politique d'attribution) |
| VM pour projet (type ADET) |
Ticket P4 → N3 (provisionnement encadré) |
Le N1 ne traite pas les alertes automatiques, mais :
- Vérifier si des tickets utilisateurs correspondent → les rattacher.
- Si l'alerte est critique et qu'aucun N2 n'a réagi en 15 min → appeler le N2 d'astreinte (contact : doc Organisation-Support §4.4).
- Ne rien manipuler, ne rien supprimer.
- Collecter : captures, en-têtes de mail complets si phishing, URL.
- Escalade directe N3, P1. Prévenir par téléphone, pas seulement par ticket.
| Symptôme signalé |
Fiche |
| Connexion impossible, mot de passe refusé |
R-01 |
| Site ne répond pas, erreur 5xx |
R-02 |
| Problème d'e-mail |
R-03 |
| Visio : audio, vidéo, accès session |
R-04 |
| Avertissement certificat |
R-05 |
| « C'est lent » |
R-06 |
| Création de compte, accès |
R-07 |
| Alerte Telegram |
R-08 |
| Phishing, piratage |
R-09 |