Une équipe conçoit un service de billetterie pour un festival régional. Le système gère sans problème la charge prévue et la revue de conception se termine par une validation. Mais le cahier des charges change : l’organisateur exige désormais que la billetterie reste opérationnelle même si un centre de données tombe en panne pendant la période de vente. Le système, désormais vulnérable, présente un point de défaillance unique, et les ingénieurs qui l’ont conçu doivent décider des modifications à apporter, des éléments à abandonner et de la manière de justifier leurs choix.
Il s'agit d'un scénario illustratif, et non d'un incident documenté. C'est la situation que vise à simuler un kata de conception système : une conception fonctionnelle sous certaines contraintes se retrouve confrontée à de nouvelles, et les ingénieurs doivent la justifier ou la modifier. Ce guide s'adresse aux responsables de la formation et aux managers d'ingénierie. Il explique ce qu'est un kata de conception système, comment en créer un, comment l'exécuter et l'évaluer, et à quel moment la formation ne suffit plus. Chaque cas et critère doit être validé par un ingénieur senior avant utilisation.
Qu'est-ce qu'un kata de conception de système ?
Un kata de conception système est un exercice de conception court et limité dans le temps. Une petite équipe reçoit un problème métier résumé en un paragraphe, esquisse une architecture, la présente à ses pairs et répond à des questions pointues. On l'appelle aussi kata d'architecture. Ce format a été créé par Ted Neward sous forme d'atelier et sa documentation, avec ses règles et le rôle du modérateur, est disponible sur [lien manquant]. Page des katas architecturaux de Neal FordLa question centrale de Neward, citée dans cet ouvrage, est la suivante : comment les organisations peuvent-elles former d’excellents architectes alors que les ingénieurs n’ont l’occasion de concevoir des systèmes que moins d’une demi-douzaine de fois au cours de leur carrière ? Un kata leur offre des répétitions supplémentaires sans risque pour la production.
Faits rapides
| Questionne toi | Réponse courte |
|---|---|
| Quelle est la tâche ? | Défendre une architecture lorsqu'une contrainte change. |
| Quelle est la taille du groupe ? | Le format original utilise des petits groupes de 3 à 5 personnes, avec un modérateur. |
| Quel est votre score ? | Un raisonnement basé sur les compromis et la réponse à une nouvelle contrainte, et non pas le diagramme le plus esthétique. |
| Un quiz sur les modèles de conception est-il suffisant ? | Non. Cela confirme les prérequis, mais pas si un ingénieur peut justifier un choix sous pression. |
| Qui valide l'affaire ? | Un responsable d'ingénierie ou un architecte senior. |
| Qu'est-ce qu'un kata ne peut pas corriger ? | Absence d'autorité en matière de conception, exigences floues et manque de temps pour concevoir correctement au travail. |
| Comment savez-vous que cela a fonctionné ? | Un nouveau cas inédit évalué selon des critères convenus, ainsi qu'un suivi des revues de conception réelles. |
1. Décrivez le problème de performance
Commencez par la tâche, pas par le sujet. La tâche consiste à défendre une architecture face à des contraintes changeantes. Concrètement, cela se manifeste lors des revues de conception, du suivi des incidents et des réunions de planification où une exigence évolue : augmentation du trafic, engagement de disponibilité plus strict, nouvelle règle de résidence des données, budget plus restreint.
Nombre d'ingénieurs savent concevoir une architecture cohérente. Plus rares sont ceux qui peuvent expliquer les compromis qu'ils seraient prêts à faire en cas de conflit entre deux objectifs, et quels éléments pourraient les amener à reconsidérer leur position. C'est précisément cette seconde compétence que le kata vise à développer.
Rédigez un énoncé de performance d'une seule phrase et faites-le vérifier par un responsable d'ingénierie : « Étant donné une architecture et une contrainte modifiée, l'ingénieur nomme ce qui ne fonctionne pas, propose un changement, indique le compromis et dit ce qu'il ne sait toujours pas. »
2. Diagnostiquer les lacunes en matière d'apprentissage et de contexte
Avant de construire quoi que ce soit, comparez la tâche avec ce que votre programme pratique et évalue actuellement.
- L'exercice pratique utilise-t-il la tâche réelle ? Si la formation enseigne des schémas isolément et que l'évaluation consiste en un test à choix multiples, personne ne s'est entraîné à défendre un choix.
- Quelle est la demande cognitive ? Dans la taxonomie révisée de Bloom, la comparaison des options par rapport aux contraintes correspond à l'analyse et à l'évaluation, tandis que la proposition d'une conception révisée relève de la création. Notre guide Faire correspondre les activités d'apprentissage à la taxonomie de Bloom montre comment adapter l'activité à ce niveau.
- Y a-t-il autre chose que le talent qui fait obstacle ? Vérifiez si les ingénieurs ont le temps de concevoir, si quelqu'un est responsable des décisions d'architecture et si les exigences sont consignées par écrit. Si une décision est prise par une personne extérieure à l'équipe, aucun kata ne changera la donne. Transmettez ces problèmes aux personnes compétentes.
3. Préparation et pratique de la conception
Attribuez à chaque étape une fonction distincte.
Préparation. Vérifiez les prérequis grâce à un diagnostic rapide : le vocabulaire utilisé par votre équipe (disponibilité, cohérence, latence, coût), les notions fondamentales qu’elle est censée maîtriser et votre propre modèle de revue de conception. Un apprentissage à votre rythme est idéal à cette étape, et une vérification des connaissances permet uniquement de confirmer les prérequis.
Pratique. Déroulez le kata. Selon le format décrit sur le site de Neal Ford, une fois l'équipe formée, l'exercice se déroule en trois phases : une phase de discussion où l'équipe définit le projet, une phase d'évaluation par les pairs où chaque équipe présente son travail et répond aux questions, et une phase de vote où les pairs donnent leur approbation (« parfait »), leur avis mitigé (« quelques points ont été omis ») ou leur désapprobation (« totalement raté »). Certaines règles sont pertinentes : les équipes peuvent formuler des hypothèses sur les technologies qu'elles ne maîtrisent pas, mais doivent les indiquer clairement, et elles ne peuvent pas présumer pouvoir constituer une équipe d'experts.
Ajouter la contrainte variable. Le kata standard propose un problème fixe. Pour développer cette compétence, ajoutez une seconde carte à mi-parcours : une contrainte modifiée que l’équipe doit gérer. Il s’agit d’un choix de conception de notre part, non prévu par les règles originales ; testez-le.
Feedback. Liez les commentaires aux décisions prises, et non à une note globale. « Vous avez changé de région, mais vous n'avez pas précisé ce qu'il advient des commandes passées pendant ce changement » est plus utile que « 3 sur 5 ».
Saisie en direct ou révision asynchrone ? L'animation en direct est particulièrement utile lorsqu'un choix est ambigu et que les ingénieurs apprennent d'un collègue plus expérimenté qui explique les raisons de son choix. La relecture asynchrone suffit pour comparer une justification écrite à un exemple commenté.
4. Travaillez sur un exemple réaliste
À titre d'exemple, un ingénieur senior doit valider le cas et les critères de réponse avant utilisation.
L'affaire. Un festival régional vend 20 000 billets en un week-end, la plupart des ventes se faisant dans les dix premières minutes. La première version du cahier des charges demande un service de réservation capable de gérer ce pic d'affluence. La solution proposée : une plateforme web unique, une base de données unique et un processus de paiement via un prestataire externe au moment de la validation de la commande.
La contrainte modifiée. À mi-parcours, l'organisateur précise : les ventes doivent se poursuivre si un centre de données est mis hors service, et aucun billet ne peut être vendu deux fois.
Une première tentative. « Ajouter un deuxième centre de données et répliquer la base de données. » L’équipe a eu recours à un composant familier, mais n’a pas précisé ce qu’il adviendra de la règle de non-double vente lorsque les deux sites ne pourront plus communiquer.
Commentaires et nouvelle tentative. L'animateur demande à l'équipe d'identifier les deux objectifs en conflit et celui qu'elle privilégierait en cas de scission du réseau. Lors de la seconde tentative, l'équipe doit choisir et décrire l'expérience client.
Une tentative plus convaincante. Nous défendrions la règle de non-double vente. En cas de scission, seul le site principal vendrait les billets, l'autre site affichant une page d'attente. Nous acceptons une disponibilité réduite pendant une courte période afin d'éviter de vendre deux fois le même siège. Nous partons du principe que cette scission est rare et de courte durée, et nous souhaiterions que l'organisateur confirme l'acceptabilité d'une page d'attente. S'il est nécessaire que les deux sites vendent des billets, nous attribuerions à l'avance des blocs de sièges distincts à chaque site, au prix de quelques sièges invendus. Notez que cette réponse nomme le conflit, prend position, indique le coût et signale les points qu'elle ignore.
Pourquoi chaque réponse est défendable ou incomplète. Évaluez chaque solution selon des critères approuvés, et non selon l'architecture préférée d'un examinateur. La première solution mentionne un composant sans proposer de compromis. La solution la plus aboutie est précise, énonce ses hypothèses et offre une alternative avec son prix.
5. Évaluer les capacités et planifier le transfert
La preuve de compétence réside dans la performance face à un cas inédit pour l'ingénieur. L'évaluation porte sur le raisonnement en matière de compromis et la réponse à une nouvelle contrainte. Une grille d'évaluation simple utilise une échelle de 0 à 2 par critère :
| Critère | Preuves observables |
|---|---|
| Exécution des tâches | Il défend l'architecture malgré la nouvelle contrainte et consigne les éléments justifiant la décision. |
| Raisonnement | Explique les contraintes pertinentes, les alternatives envisagées et ce qui reste incertain. |
| Frontières | Respecte les procédures de conception approuvées et demande de l'aide en cas de manque d'informations ou d'autorisation. |
Ancrages : 0 signifie absent ou non pris en charge, 1 signifie partiel avec des omissions pertinentes, et 2 signifie complet et justifié par rapport aux critères convenus. Définissez séparément les erreurs critiques, telles que le non-respect d’une exigence de sécurité ou de protection des données, afin qu’une note globale ne puisse pas en masquer une. Cette grille d’évaluation est une proposition, et non une norme de préparation validée : adaptez-la avec un responsable technique et testez-la. Consultez notre guide pour Concevoir une pratique interactive avec des retours utiles explique comment rédiger des commentaires qui permettent d'éclairer les décisions.
Planifiez le transfert de compétences de manière réfléchie. Après l'exercice pratique, demandez à chaque ingénieur de présenter une décision de conception concrète lors d'une revue et posez-lui les mêmes questions. L'analyse objective d'un incident passé constitue également un bon tremplin vers le travail réel ; consultez notre guide. Examens d'incidents sans reproche.
Là où la livraison interactive est utile
Les formats interactifs permettent à chacun de s'engager avant la réunion de groupe. Lors d'une session kata en direct, un animateur peut présenter la contrainte modifiée, demander à chaque membre de l'équipe d'indiquer le compromis qu'il ferait et pourquoi, puis révéler la répartition avant le début de la discussion. Le vote par les pairs à la fin du format original est facile à reproduire. Ce même cas peut être réalisé à son propre rythme, à titre de préparation ou pour les ingénieurs absents. AhaSlides favorise l'apprentissage interactif et permet d'alterner facilement entre présentation en direct et à son propre rythme. C'est un outil de présentation et d'apprentissage, et non un espace pour dessiner ou exécuter des schémas d'architecture ; conservez donc vos diagrammes sur un tableau blanc ou dans votre outil de conception. Vérifiez la compatibilité de toute fonction de création, de retour d'information ou de reporting que vous prévoyez d'utiliser avec votre flux de travail. Pour obtenir des conseils sur le choix des formats, consultez notre article sur Quand utiliser l'apprentissage adaptatif, interactif et en direct.
Mesurez ce qui a changé
Déterminez à l'avance ce qui démontrerait que les ingénieurs sont capables de défendre une architecture face à des contraintes évolutives. Comparez le raisonnement sur les compromis dans un cas inédit avec une situation de référence établie avant le programme. Définissez les participants, le dénominateur et le calendrier. Si les résultats s'améliorent, examinez les autres changements survenus pendant la même période, tels qu'un nouveau modèle de revue de conception, un changement de personnel ou un incident ayant attiré l'attention, avant d'attribuer la réussite à la formation.
Des contraintes qui pourraient subsister
- Autorité en matière de conception. Si l'équipe ne prend pas la décision, la mise en pratique a un effet limité.
- Temps. Un kata prend des heures ; les vrais projets prennent des semaines et impliquent des données qu'un kata ne peut pas fournir.
- Couverture du dossier. Un cas particulier met en évidence certains compromis. Une note ne reflète pas de manière générale le jugement d'un ingénieur.
- Complexité. Une architecture plus complexe n'est pas forcément meilleure, il ne faut donc pas privilégier le plus grand nombre de composants.
- Transfert. Réussir un atelier ne signifie pas réussir une évaluation sous pression ; il est donc important de vérifier sa performance après le kata, en situation réelle.
Signalez ces problèmes aux sponsors dès le début et prévoyez des correctifs distincts. Un kata permet aux ingénieurs d'améliorer leurs explications et leurs justifications. Il ne leur confère ni l'autorité ni le temps nécessaires.
Foire aux questions
Qu'est-ce qu'un kata de conception de système ?
Un exercice de conception court et limité dans le temps, où une petite équipe esquisse une architecture pour un problème métier, la présente à ses pairs et répond à des questions complexes. On l'appelle aussi un kata d'architecture.
Combien de personnes devraient composer une équipe ?
Le format original utilise de petits groupes de 3 à 5 personnes, généralement au sein de 4 à 10 groupes dans une même salle. Veillez à ce que les groupes soient suffisamment petits pour que chacun puisse prendre la parole.
Comment évalue-t-on un kata de conception de système ?
Présentez un nouveau cas et évaluez le raisonnement sur les compromis à faire, ainsi que la réponse à une contrainte modifiée par rapport aux critères convenus. Un vote entre pairs constitue un retour d'information utile, mais ne saurait à lui seul constituer une note.
Par où commencer
Choisissez une décision de conception récurrente dans votre organisation et rédigez une brève analyse (un paragraphe) à son sujet. Intégrez une contrainte modifiée, faites valider l'analyse et les critères de réponse par un responsable technique, puis élaborez une grille d'évaluation à trois critères incluant une liste d'erreurs critiques. Testez-la auprès d'une équipe avant de la déployer à plus grande échelle.
Pour voir comment un kata peut être exécuté en direct avec votre propre équipe et être réutilisé à votre propre rythme par la suite, explorez AhaSlides.
