Onboarding et connaissance produit, rédigés à partir de votre propre documentation.

Wikis techniques, runbooks et spécifications produit deviennent des parcours de formation pour les nouvelles recrues, les équipes support et les clients. Les exemples viennent de votre stack, pas d'un manuel générique.

Parler d'un projet Voir le module d'exemple

Apprenants: Développeurs, équipes support et commerciales, nouvelles recrues, clients et partenaires
Thèmes types: Onboarding technique, Pratiques de sécurité et de protection des données, Formation produit pour les équipes commerciales et support, Académies clients et partenaires
Module d'exemple: Traiter les données personnelles dans nos services

Une leçon finalisée telle que l'apprenant la voit : illustration, texte de la leçon et lecteur audio.

01 Thèmes

Ce que nous couvrons habituellement

1 Onboarding technique
2 Pratiques de sécurité et de protection des données
3 Formation produit pour les équipes commerciales et support
4 Académies clients et partenaires

Tout autre sujet fonctionne de la même façon : à partir de vos documents ou d'un brief.

02 Formats

Ce qui fonctionne le mieux pour ces apprenants

Une personne gravit un escalier de cinq vignettes-documents reliées par un chemin en pointillés jusqu'à un drapeau, en partant d'une pile de feuilles volantes.

Parcours de formation

Construits à partir de vos documents et runbooks, dans un ordre logique.

Une personne devant une tablette affichant un quiz de mise en situation avec une sonnerie d'alarme, une carte question et trois réponses, dont une cochée.

Questions de mise en situation

Inspirées des incidents que vos équipes gèrent réellement.

Un cube central diffuse des contenus de formation, via des connexions prise et cloud, vers trois applications différentes : un portail, une plateforme de cours et un tableau de bord.

Diffusés via l'API

Dans votre propre portail, LMS ou produit.

03 Module d'exemple

Traiter les données personnelles dans nos services

Démo disponible en Une autre langue ? Contactez-nous

1
Ce qui constitue une donnée personnelle chez nous

Une donnée personnelle est toute information permettant d'identifier une personne physique, seule ou combinée à une autre. Une adresse e-mail, un identifiant client, une adresse IP et un identifiant d'appareil en font partie. Tout comme un ticket de support qui nomme l'utilisateur. Si vous pouvez savoir de qui il s'agit, traitez-la comme une donnée personnelle, même sans le nom.

Narration, 0:26
2
Journaliser sans divulguer

Les logs vont plus loin que le code : vers les tableaux de bord, les fournisseurs, les sauvegardes. Journalisez donc l'événement, pas la personne. Écrivez l'identifiant utilisateur plutôt que l'e-mail, et n'affichez jamais le corps d'une requête ni un jeton. Avant d'ajouter une ligne de log, demandez-vous ce qu'un inconnu pourrait en apprendre. Masquez ce que vous devez conserver et fixez une durée de conservation courte.

Narration, 0:26
3
Demandes d'accès et de suppression

Les personnes peuvent demander quelles données nous détenons sur elles, et nous demander de les supprimer. Ces demandes arrivent via le formulaire de confidentialité et doivent recevoir une réponse avant l'échéance indiquée sur le ticket. Ne cherchez jamais à la main. Ouvrez la demande dans l'outil de confidentialité, qui retrouve les données dans tous nos services et lance la suppression. Les sauvegardes sont purgées selon leur calendrier habituel.

Narration, 0:26
4
Mise en situation : une adresse e-mail dans une stack trace

Un collègue colle une stack trace dans le chat de l'équipe. À mi-chemin, l'adresse e-mail d'un client apparaît dans un message d'erreur. Que faites-vous ? Ne la transférez pas. Supprimez le message, prévenez votre collègue et ouvrez un incident pour la fuite. Corrigez ensuite la cause, pour que le code n'insère plus l'e-mail dans le texte d'erreur.

Narration, 0:24