Équipes

Création d'une équipe

Naviguez vers la page Équipes depuis la barre latérale d'administration, puis cliquez sur le bouton « Créer une équipe ». Saisissez un nom d'équipe et cliquez sur enregistrer. Les équipes sont plates — il n'y a pas de hiérarchie ou d'imbrication. Chaque équipe est un simple groupe d'utilisateurs.

Gestion des membres

Ajoutez des membres à une équipe depuis la liste Utilisateurs. Chaque utilisateur peut appartenir à une seule équipe à la fois — attribuer un utilisateur à une nouvelle équipe le retire automatiquement de son équipe précédente. Pour retirer un membre, cliquez sur le bouton × à côté de son nom dans la vue détail de l'équipe.

Synchronisation de groupe SCIM

Si vous utilisez le provisionnement SCIM, les groupes de votre fournisseur d'identité (Okta, Azure AD, etc.) se synchronisent automatiquement comme équipes dans SecureCodingHub. Le champ ExternalGroupId correspond à l'identifiant de groupe dans votre IdP, garantissant que les équipes restent synchronisées lorsque les groupes changent dans votre annuaire.

Attribution de la formation aux équipes

Lors de la création d'une affectation, sélectionnez « Équipe » comme type de destinataire et choisissez l'équipe cible. Tous les membres actuels de l'équipe recevront l'affectation. Les utilisateurs qui rejoignent l'équipe plus tard recevront également automatiquement l'affectation — pas besoin de réattribuer.

Vue d'ensemble des équipes

Voici à quoi ressemble la page Équipes dans le panneau d'administration :

Détail de l'équipe

Cliquez sur une équipe pour voir ses membres et gérer la liste :

Suppression d'une équipe

Supprimer une équipe retire l'entité équipe mais ne supprime pas les utilisateurs qu'elle contient. Tous les membres deviennent non attribués et peuvent être ajoutés à une équipe différente. Toutes les affectations actives ciblant l'équipe supprimée resteront mais ne s'appliqueront plus aux nouveaux utilisateurs.

Conception de votre structure d'équipe

Il n'y a pas de façon unique correcte de modéliser les équipes. La structure qui fonctionne pour une entreprise de cinquante ingénieurs ne passera pas à cinq cents, et la structure qui fonctionne pour une organisation axée produit ne correspondra pas à un cabinet de conseil de services. Avant de créer votre première équipe, décidez quel signal vous voulez le plus faire ressortir au niveau de l'équipe — la maîtrise des langages, la propriété du produit ou l'ancienneté — car cette décision détermine quelle taxonomie suivre.

Trois taxonomies courantes

Par langage ou stack. Les équipes comme Backend Java, Frontend TypeScript et Mobile Swift fonctionnent bien lorsque le contenu de formation est spécifique au langage et lorsque vous voulez comparer deux groupes backend l'un à l'autre. L'inconvénient est que les ingénieurs qui travaillent à travers les stacks (un schéma courant dans les petites organisations) doivent être placés dans leur stack principale et la compétence secondaire est invisible.

Par ligne de produits. Les équipes comme Payments, Identity et Checkout correspondent à la façon dont le travail d'ingénierie est réellement organisé dans la plupart des entreprises produit. Cette taxonomie facilite pour un chef de produit ou un responsable sécurité de regarder le tableau de bord et de répondre à la question « comment l'équipe Payments progresse sur la formation pertinente PCI » sans filtrer. Le compromis est que comparer la maîtrise des langages à travers les produits nécessite des rapports transversaux.

Par ancienneté ou rôle. Les équipes comme Senior Engineers, Engineers et Junior Engineers aident lorsque les parcours de formation diffèrent selon le niveau d'expérience. Cela fonctionne bien aux côtés de l'une des deux taxonomies ci-dessus comme regroupement secondaire, moins bien comme seule taxonomie.

Développeurs multi-squads et métriques au niveau de l'équipe

Chaque utilisateur appartient à exactement une équipe à la fois, donc les ingénieurs qui partagent réellement leur temps entre deux squads nécessitent un jugement. La règle la plus simple est de les attribuer à l'équipe qui possède la majorité de leur travail ce trimestre et de revoir le mappage lors de votre revue trimestrielle de la liste des utilisateurs. Si un développeur tourne souvent, placez-le sur son équipe d'origine et appuyez-vous sur les affectations individuelles pour le travail de rotation plutôt que de jongler avec l'appartenance d'équipe toutes les quelques semaines.

Au niveau de l'équipe, les métriques qui comptent le plus sont le taux de complétion par rapport à la formation attribuée, le score moyen par sujet et le nombre d'utilisateurs actifs au cours des trente derniers jours. La première vous dit si l'équipe fait le travail, la deuxième vous dit si elle apprend, et la troisième vous dit si l'équipe est engagée du tout. Une équipe avec un taux de complétion élevé mais un faible nombre d'utilisateurs actifs a généralement une ou deux personnes qui portent toute la liste — vaut la peine d'être étudié lors de votre prochain entretien individuel avec le chef d'équipe.