Réponse aux incidents

En vigueur le 28 octobre 2026

Portée

Ce processus couvre les incidents qui touchent TreeCraft : hiérarchies de tickets. TreeCraft fonctionne sur Atlassian Forge : elle dépend donc aussi de Jira Cloud et de Forge. Les problèmes de ces plateformes relèvent d’Atlassian et sont signalés sur la page d’état d’Atlassian. Nous les suivons et, lorsqu’ils touchent l’application, nous en informons les clients.

Un incident de sécurité est tout accès non autorisé, réel ou soupçonné, à des données de clients, toute atteinte à la sécurité de l’application ou, comme le dit Atlassian, un problème qui dégrade sensiblement les systèmes d’Atlassian. Un incident opérationnel est tout autre événement qui rend l’application indisponible, erronée ou inutilisablement lente.

Rôles

Responsable de l’incident : le propriétaire de Logiciels Plugincraft inc., ou la personne qu’il désigne. Le responsable prend en charge l’incident de la détection à l’analyse, fixe la gravité et parle d’une seule voix aux clients et à Atlassian. Personne-ressource en sécurité : info@plugincraft.ca.

Jours ouvrables et engagements de réponse

Les jours ouvrables vont du lundi au vendredi, et les heures ouvrables sont les heures de soutien : de 8 h à 17 h, heure de l’Est. Un message reçu en dehors des heures ouvrables compte à partir du début de la période ouvrable suivante. Voici les délais auxquels Plugincraft s’engage. Ils correspondent aux minimums qu’Atlassian fixe aux partenaires du Marketplace dans le programme Atlassian Enterprise Certified, ou les améliorent.

Atlassian envoie des avis d’essai pour vérifier que les coordonnées des partenaires fonctionnent. Nous y répondons comme à de vraies alertes. Notre personne-ressource en sécurité est info@plugincraft.ca.

1. Détection

Les incidents nous parviennent par :

• les signalements de clients, par la page de contact et info@plugincraft.ca;
• les signalements de vulnérabilités (voir la Politique de divulgation des vulnérabilités) et, une fois l’application inscrite, ceux du programme de primes aux bogues de sécurité du Marketplace d’Atlassian;
• les avis d’Atlassian sur Forge, Jira ou le Marketplace;
• les journaux de l’application, qui consignent les échecs sous forme d’identifiants, de nombres, de statuts et de codes d’erreur (voir Journalisation des données), et les chiffres d’utilisation de la console des développeurs d’Atlassian;
• les avis de sécurité sur les bibliothèques que l’application utilise, lorsque nous en prenons connaissance.

Chaque jour ouvrable, nous consultons les journaux de l’application et les chiffres d’erreurs de la console des développeurs d’Atlassian, et nous lisons les avis d’Atlassian. L’analyse de recherche de secrets décrite dans l’Aperçu de la sécurité s’exécute automatiquement, et nous donnons suite à ses constats. Aucune analyse automatisée des dépendances ni analyse statique ne s’exécute encore; elles sont en cours d’ajout.

2. Triage et classement

Le responsable de l’incident confirme le signalement, note l’heure de réception et fixe une gravité dans le délai de première réponse ci-dessous. La gravité est revue à mesure que les faits arrivent.

Les vulnérabilités de sécurité sont aussi corrigées dans les délais de la politique de correction des bogues de sécurité d’Atlassian : 10 jours pour Critique, 4 semaines pour Élevée, 12 semaines pour Moyenne et 25 semaines pour Faible (voir l’Aperçu de la sécurité). Lorsqu’une vulnérabilité a aussi une gravité ici, nous respectons le délai le plus court. La résolution signifie que le problème est corrigé dans une version publiée, ou qu’une solution de rechange est en place et qu’aucun dommage ne se poursuit. Les demandes de soutien critiques, soit les gravités 1 et 2, reçoivent une première réponse dans les 24 heures, cinq jours ouvrables par semaine. Heures de soutien : de 8 h à 17 h, heure de l’Est, du lundi au vendredi.

3. Confinement et résolution

• Confiner : limiter d’abord les dégâts. Selon l’incident, cela peut vouloir dire désactiver l’API REST et les outils MCP de l’application (l’interrupteur dont dispose un administrateur et que nous pouvons lui demander d’utiliser), retirer une version défectueuse ou en livrer une corrigée.
• Enquêter : trouver la cause ainsi que les sites et les données touchés, à l’aide des journaux de l’application. Comme les journaux ne contiennent aucun contenu de clients, nous pouvons demander à un administrateur un paquet de soutien, ce qui reste son choix.
• Corriger : livrer le correctif sous forme de nouvelle version de l’application sur Forge, et le vérifier avant de clore l’incident.
• Vérifier : confirmer auprès des personnes qui l’ont signalé et surveiller les journaux par la suite.

4. Communication

• Atlassian. Pour un incident de sécurité, nous avisons Atlassian avec diligence, et au plus tard 24 heures après en avoir pris connaissance, en ouvrant un billet P1, et nous faisons le point avec Atlassian au moins toutes les 6 heures jusqu’à la résolution de l’incident. Cela suit les lignes directrices d’Atlassian sur la gestion des incidents de sécurité des applications (en anglais). Les partenaires Forge admissibles peuvent aussi travailler directement avec la sécurité d’Atlassian par son programme d’intervention en cas d’incident de sécurité pour les partenaires (en anglais), et nous l’utilisons lorsque nous sommes admissibles.
• Clients. Nous informons les administrateurs des sites touchés par courriel, à la personne-ressource technique qu’Atlassian donne aux partenaires du Marketplace pour chaque site, et, une fois qu’elle existera, par un avis sur la page d’état. Pour un incident de sécurité, nous visons à le faire dans les 72 heures suivant sa découverte, avec le modèle de communication d’incident qu’Atlassian recommande. Mises à jour d’un incident qui se poursuit : au moins toutes les 24 heures pour la gravité 1 et tous les 2 jours ouvrables pour la gravité 2, jusqu’à sa résolution.
• Autorités de protection des renseignements personnels. Si un incident de confidentialité touchant des renseignements personnels présente un risque de préjudice sérieux, nous en avisons les personnes concernées et la Commission d’accès à l’information du Québec avec diligence, comme la loi l’exige, et nous tenons un registre de tous les incidents (voir la politique de confidentialité).
• État du service. Une page d’état sera publiée avec la fiche du Marketplace. Pour une question de sécurité urgente, mettez « URGENT » au début de l’objet de votre message.

5. Analyse après incident

Après chaque incident de gravité 1 et de gravité 2, et après tout incident de sécurité, le responsable de l’incident rédige une analyse dans un délai de 10 jours ouvrables suivant la résolution de l’incident. Elle couvre :

• une chronologie de la détection à la résolution;
• la cause première, ainsi que les sites et les données touchés;
• ce qui a fonctionné et ce qui n’a pas fonctionné dans la détection, le triage et la communication;
• si un signe de compromission subsiste;
• si la journalisation doit être améliorée;
• les mesures pour éviter un incident semblable, avec un responsable et une date pour chacune;
• les changements à ce processus.

Pour un incident de sécurité, nous soumettons les constats par le billet d’origine auprès d’Atlassian. Nous communiquons un résumé aux clients touchés. Nous révisons ce processus au moins une fois par an et après chaque incident de gravité 1.

Documents connexes

• Aperçu de la sécurité
• Politique de divulgation des vulnérabilités
• Journalisation des données
• Traitement des données : conservation et suppression
• Politique de confidentialité