Documentation NICOPS

1. Prise en main

Créez votre compte depuis la page de connexion (« Créer un compte »). Cela crée automatiquement une organisation dont vous devenez administrateur, sur le plan Starter (gratuit). L'inscription nécessite d'accepter la politique de confidentialité et un mot de passe d'au moins 12 caractères comprenant une majuscule, une minuscule, un chiffre et un caractère spécial.

1. Confirmez votre adresse e-mail via le lien reçu.
2. Connectez-vous et accédez au tableau de bord.
3. Invitez vos collègues depuis Utilisateurs, en leur attribuant un rôle.

2. Services et supervision

Un service représente un endpoint à surveiller : HTTP/HTTPS, API REST, port TCP, base de données ou container Docker. Chaque service appartient à un projet et hérite de son organisation.

• Type HTTP : vérifie qu'une URL répond (code 2xx/3xx attendu).
• Type API : comme HTTP, avec en plus une vérification de valeur métier possible (ex. un champ de la réponse JSON doit valoir une valeur précise) — utile pour détecter un bug silencieux (200 OK mais donnée fausse).
• Types TCP, base de données et Docker : vérifient qu'un port répond ou qu'un service est joignable.

L'intervalle de vérification minimum dépend de votre plan (5 min en Starter, 1 min en Pro, 30 s en Enterprise). Un statut up/dégradé/down est calculé à chaque check et affiché en temps réel.

3. Incidents

Un incident est ouvert automatiquement lorsqu'un service passe en panne ou en dégradation de façon persistante, et résolu automatiquement à son rétablissement. L'historique complet (durée, sévérité, service concerné) est consultable depuis Incidents.

4. Alertes

Une règle d'alerte associe un service à une condition de déclenchement (ex. 3 échecs consécutifs) et à un ou plusieurs canaux de notification.

• Email : toujours disponible, tous plans confondus.
• Slack et webhook personnalisé : disponibles à partir du plan Pro.
• PagerDuty : réservé au plan Enterprise.

Vous pouvez mettre une règle en silence temporairement (par exemple pendant une maintenance planifiée) sans la supprimer.

Règle par défaut : à la création d'un service, une règle est ajoutée automatiquement — e-mail à la personne qui a créé le service après 2 échecs consécutifs. Vous pouvez la modifier, la mettre en silence ou la supprimer depuis Alertes.

Responsables des alertes

Pour qu'une autre personne que le créateur du service reçoive les e-mails, choisissez des responsables des alertes parmi les membres de l'organisation, dans le formulaire du projet ou du service.

• Sur un projet : les responsables reçoivent les alertes de tous les services du projet.
• Sur un service : ses responsables remplacent ceux du projet, pour ce service uniquement.
• Les responsables reçoivent les e-mails à la place des adresses des règles d'alerte e-mail (panne et erreurs de logs AWS). Les règles décident toujours quand alerter (seuil, silence, activation) ; Slack et webhook ne changent pas.
• Sans responsable, ce sont les adresses des règles qui reçoivent les e-mails, comme avant.
• Seuls les membres de l'organisation à l'e-mail vérifié peuvent être choisis.

Suivre un projet ou un service

• L'étoile « Suivre » (liste des projets, liste et fiche des services) est ouverte à tous les rôles et ne concerne que vous.
• Un élément suivi s'affiche en tête de votre tableau de bord ; suivre un projet revient à suivre tous ses services.
• Vous recevez aussi ses e-mails d'alerte, en plus des responsables ou des adresses des règles (il faut toujours une règle e-mail active). Les e-mails d'erreurs de logs AWS ne sont envoyés qu'aux abonnés Administrateur ou Ingénieur.

5. Logs AWS et alertes sur erreur

Environnement pris en charge : actuellement, seul AWS est inclus dans l'offre — les logs CloudWatch Logs des applications déployées sur AWS (ECS). Les autres environnements (Azure, Google Cloud, Datadog, serveurs hébergés hors AWS…) ne sont pas encore pris en charge.

Fonctionnement

Un service peut être rattaché au groupe de logs CloudWatch de son application. Ce rattachement est effectué par un super-administrateur depuis le formulaire du service (champ « Groupe de logs CloudWatch »).

• Consultation : la fiche du service affiche un panneau « Logs AWS » (15 min à 24 h, filtre « Erreurs uniquement », recherche de texte insensible à la casse avec surlignage, 300 lignes les plus récentes). Ce panneau est réservé aux rôles Administrateur et Ingénieur ; il n'est pas visible pour le rôle Lecteur.
• Détection : toutes les minutes, NICOPS recherche les nouvelles lignes contenant ERROR, Error, Exception, FATAL ou HttpError.
• Erreurs HTTP (400, 401, 404, 500…) : la plupart des frameworks, dont NestJS, ne les écrivent pas dans les logs. Pour qu'elles apparaissent, l'application doit écrire une ligne par réponse en erreur contenant l'un de ces mots — par exemple « HttpError HTTP 404 GET /api/... », comme le fait NICOPS lui-même. Pour couper une erreur fréquente et sans gravité (ex. « HTTP 401 »), ajoutez-la aux erreurs acceptées.
• Notification : un e-mail avec le nombre d'erreurs et les dernières lignes est envoyé aux responsables des alertes du service (ou de son projet), à défaut aux destinataires e-mail de ses règles d'alerte actives. Il faut au moins une règle e-mail active — au plus un e-mail toutes les 15 minutes par service ; les erreurs survenues entre-temps sont comptabilisées dans l'e-mail suivant.

Les logs ne sont pas copiés dans NICOPS : ils sont lus à la demande dans CloudWatch.

Erreurs acceptées

Certaines erreurs sont connues et sans gravité (par exemple un délai dépassé ponctuel vers un service tiers). Vous pouvez demander à ne plus être averti pour celles-ci, service par service.

1. Ouvrez la fiche du service, panneau « Logs AWS ».
2. Survolez une ligne d'erreur et cliquez sur « Ignorer » (ou utilisez « + Ajouter » dans la section « Erreurs acceptées »).
3. Ajustez le texte proposé pour ne garder que la partie stable du message (sans date, identifiant ou numéro variable), puis validez.

• Règle : une erreur est acceptée si son message contient l'un des textes de la liste, sans tenir compte des majuscules.
• Une erreur acceptée reste visible dans le panneau (grisée, marquée « acceptée ») mais ne déclenche plus d'e-mail et n'est plus comptée.
• Chaque texte doit faire au moins 8 caractères (pour éviter de couper toutes les alertes par mégarde) et au plus 200 ; 50 textes maximum par service.
• Seuls les administrateurs de l'organisation peuvent modifier la liste ; les ingénieurs la consultent. Chaque ajout ou retrait est enregistré dans le journal d'audit.
• Pour être de nouveau averti, retirez le texte de la liste (croix à côté du texte).

Configuration côté AWS

NICOPS s'authentifie auprès d'AWS avec le rôle IAM de la tâche ECS sur laquelle il tourne : aucune clé d'accès AWS n'est stockée dans NICOPS. Ce rôle doit autoriser l'action logs:FilterLogEvents sur les groupes de logs à surveiller — de préférence limitée à un préfixe (par exemple arn:aws:logs:<région>:<compte>:log-group:/ecs/<préfixe>/*) plutôt qu'à tous les groupes du compte. Aucun redéploiement n'est nécessaire après l'ajout de cette permission.

Sécurité

• Secrets masqués : les jetons, clés et en-têtes d'authentification reconnus sont remplacés par « [secret masqué] », dans le panneau comme dans les e-mails.
• Destinataires contrôlés : les e-mails d'erreurs de logs ne partent qu'aux comptes NICOPS à l'e-mail vérifié de l'organisation du service. Une adresse extérieure ajoutée à une règle d'alerte ne reçoit pas d'extraits de logs.
• Isolation : seul un super-administrateur peut rattacher un groupe de logs, et les logs de la plateforme NICOPS elle-même ne peuvent être rattachés qu'à un service de sa propre organisation.
• Contenu : évitez d'écrire des données personnelles ou des secrets dans les logs de vos applications — le masquage ne reconnaît que les formats connus.

6. Projets et groupes

Les services sont organisés en projets (ex. « Infrastructure Prod », « API Facturation »). Les projets peuvent eux-mêmes être regroupés pour structurer la vue Services par équipe ou par domaine.

7. Qualité de code

En connectant un dépôt GitLab ou GitHub, NICOPS peut revoir automatiquement les merge requests (qualité, risques), suivre les résultats de pipelines CI et scanner le code à la recherche de secrets exposés (clés API, identifiants).

Le jeton d'accès à votre dépôt est chiffré avant stockage. Cette fonctionnalité est disponible à partir du plan Pro (avec seuils personnalisés sur Enterprise).

Notifications par e-mail

NICOPS peut prévenir automatiquement par e-mail l'auteur d'un commit :

• Pipeline CI passée en échec : les 20 dernières lignes de log des jobs en erreur.
• Review IA terminée : score, résumé et points relevés.
• Scan de secrets ayant détecté des secrets potentiels : emplacement et type uniquement, jamais leur valeur. Le scan se lance manuellement.

Activation et destinataires :

• Désactivées par défaut. Un administrateur les active depuis Paramètres → Notifications, après avoir accepté les recommandations de sécurité affichées.
• Incluses à partir du plan Pro. Si le plan ne les inclut plus, aucun e-mail n'est envoyé, même si le réglage reste activé.
• Seuls les membres de l'organisation au compte NICOPS vérifié reçoivent ces e-mails : l'adresse git du développeur (user.email) doit être celle de son compte, sinon il ne reçoit rien. Aucun e-mail n'est envoyé à une adresse inconnue de NICOPS.
• Les secrets aux formats connus sont masqués dans les extraits de log. Déclarez aussi vos variables CI sensibles comme masquées (« Masked » dans GitLab CI).
• Le jeton du dépôt doit pouvoir lire les logs de CI (GitLab : read_api ; GitHub : lecture des Actions).

8. Rapports

Un rapport d'uptime basique (JSON, sur une période) est disponible pour tous les plans. L'export CSV et les rapports mensuels par projet sont disponibles à partir du plan Pro ; leur génération planifiée et l'accès via API sont réservés au plan Enterprise.

9. Utilisateurs et rôles

10. Compte et mot de passe

• Changer son mot de passe : Paramètres → Sécurité. Le mot de passe actuel est demandé, et le nouveau doit respecter la politique (12 caractères minimum, majuscule, minuscule, chiffre, caractère spécial) et être différent de l'actuel.
• Mot de passe perdu : cliquez sur « Mot de passe oublié ? » sur la page de connexion, ou demandez à un administrateur de votre organisation de vous envoyer un lien depuis la page Utilisateurs. Le lien est valable 1 heure et utilisable une seule fois.

11. Plans et limites

Chaque organisation est rattachée à un plan (Starter, Pro ou Enterprise) qui détermine ses limites d'usage (utilisateurs, projets, services, historique) et les fonctionnalités disponibles. Voir la grille tarifaire sur la page d'accueil pour le détail.

Passage au plan Pro : un administrateur de l'organisation peut payer en ligne depuis Paramètres → Abonnement (carte bancaire ou mobile money, via NicoPay). Le plan est activé dès la confirmation du paiement. Le plan Enterprise est sur devis : contactez notre équipe.

12. Console (super-administrateurs)

Les comptes marqués super-administrateur (attribuable uniquement en base de données, jamais via l'interface) ont accès à un onglet Console supplémentaire : vue d'ensemble de la plateforme, gestion de toutes les organisations, gestion des plans tarifaires et de leurs limites (appliquées immédiatement), et gestion des utilisateurs toutes organisations confondues (changement de rôle, envoi d'un lien de réinitialisation de mot de passe, suppression). La suppression d'une organisation efface toutes ses données et demande de saisir son nom pour confirmer. Les super-administrateurs sont aussi les seuls à pouvoir rattacher un groupe de logs AWS à un service.