Guide d’entretien de data engineer

Méthode — Fonction de fenêtre avec ordre déterministe

Utilisez une fonction de fenêtrage pour attribuer un numéro à chaque ligne au sein d’une partition par event_id. Triez par ordre décroissant sur la colonne temporelle la plus fiable, comme ingestion_timestamp ou updated_at. Si des égalités sont possibles, ajoutez un critère de départage déterministe, par exemple source_sequence_number ou le nom du fichier source. Le modèle de requête consiste à sélectionner les lignes, calculer row_number() over (partition by event_id order by ingestion_timestamp desc, source_sequence_number desc), puis conserver row_number = 1. Le point essentiel est le déterminisme. Si deux enregistrements ont le même horodatage et qu’aucun critère ne les départage, le résultat peut varier entre deux exécutions. Précisez également si le dernier événement correspond à la date d’ingestion, à la date de l’événement ou à la dernière mise à jour dans le système source. En production, je surveillerais le taux de doublons, les événements tardifs, les event_id manquants et les variations inattendues des indicateurs en aval provoquées par la déduplication.

Méthode — Filtrez les événements actifs -> normalisez la date -> regroupez par date et par utilisateur

Commencez par définir un utilisateur actif. Tous les événements ne doivent généralement pas être comptés : pages vues passives, robots, actualisations en arrière-plan et utilisateurs internes peuvent être exclus. Retenez des actions significatives pour le produit, comme démarrer une session, effectuer un achat, envoyer un message ou utiliser une fonctionnalité. Créez une transformation qui filtre les événements éligibles, convertit leurs horodatages dans le fuseau horaire de référence, regroupe par date d’activité et identifiant utilisateur, puis produit une ligne par utilisateur actif et par jour. Pour une table agrégée, comptez les utilisateurs distincts chaque jour. Pour une table destinée aux analyses détaillées, conservez la date, l’identifiant, la plateforme, le pays et la première heure d’activité. En production, tenez compte du fuseau horaire, des événements tardifs, du filtrage des robots et des tests, des utilisateurs supprimés, des doublons et du partitionnement par date d’activité. Dans un traitement incrémental, retraitez les partitions récentes pour intégrer les événements tardifs, et pas uniquement la journée en cours. Validez enfin le résultat : rapprochez le nombre d’utilisateurs actifs des événements sources, surveillez les variations quotidiennes et vérifiez la cohérence par segment.

Méthode — Portée -> plan de requête -> croissance des données -> jointures -> partitions -> changements récents

Vérifiez d’abord si le problème concerne uniquement cette requête, l’ensemble de la charge de l’entrepôt de données ou l’infrastructure. Si de nombreuses requêtes ralentissent, la capacité du cluster, une hausse générale de la charge ou une dégradation du service peuvent être en cause. Si une seule requête est touchée, examinez son code et les données qu’elle traite. Passez en revue les changements récents : croissance des tables, évolution du schéma, nouvelles jointures, modification des filtres, absence d’élagage des partitions, statistiques obsolètes, asymétrie des données, jointures qui multiplient les lignes ou ajout d’opérations DISTINCT et ORDER BY. Examinez le plan d’exécution s’il est disponible. Les causes fréquentes incluent des jointures effectuées à la mauvaise granularité, l’absence de filtre de date, des jointures plusieurs-à-plusieurs, la lecture de toutes les partitions, des fonctions de fenêtre inefficaces, des échanges de données volumineux ou l’application de fonctions aux colonnes de partition, qui empêche leur élagage. Les corrections possibles comprennent le filtrage en amont, la préagrégation, l’ajout de filtres de partition, le partitionnement et le tri adaptés, la matérialisation de modèles intermédiaires, la mise à jour des statistiques, la réduction du nombre de colonnes sélectionnées et la correction des jointures. Je mettrais aussi en place un suivi de la durée d’exécution, des octets analysés, du nombre de lignes et des coûts.

Méthode — Processus métier -> faits -> dimensions -> granularité -> métriques

Commencez par les principaux processus métier : navigation, panier, commandes, paiements, expéditions, retours, remboursements, stocks et attribution marketing. Selon l’usage, chaque processus peut devenir une table de faits ou un modèle d’événements. Les tables de faits importantes comprennent fact_orders, avec une ligne par commande, fact_order_items, avec une ligne par produit et par commande, ainsi que fact_payments, fact_refunds, fact_shipments et fact_inventory_snapshot. Les dimensions comprennent notamment dim_customer, dim_product, dim_date, dim_store ou dim_warehouse, dim_channel et dim_campaign. Définissez explicitement la granularité. Le chiffre d’affaires par catégorie de produit doit généralement être calculé au niveau des lignes de commande, et non des commandes. Les indicateurs du cycle de vie client peuvent utiliser une granularité par client ou par abonnement. L’analyse des stocks peut nécessiter un instantané quotidien. Tenez également compte des attributs client ou produit à évolution lente, des remboursements et annulations, des remises au niveau de la commande ou de la ligne, des devises, des taxes, de la livraison, des commandes sans compte et des données reçues en retard. Je définirais des indicateurs de référence et construirais des modèles sémantiques ou des data marts pour la finance, le marketing, le produit et les opérations. La validation consiste notamment à rapprocher le chiffre d’affaires des données financières, le nombre de commandes des systèmes transactionnels, les remboursements des paiements et les stocks des systèmes d’entrepôt.

Méthode — Type 1 par rapport à Type 2 selon les besoins historiques

L’approche correcte dépend de la pertinence de l’exactitude historique. Le Type 1 écrase les anciennes valeurs, ce qui est simple et utile lorsque seule la dernière valeur compte. Le Type 2 préserve l’historique en créant une nouvelle ligne de dimension pour chaque changement d’attribut, généralement avec effective_start_date, effective_end_date, current_flag, et une clé de substitution. Exemple : si une clientèle passe de la région Ouest à la région Est, le Type 1 mettrait à jour la ligne de client vers l’Est. Les rapports de revenus historiques montreraient désormais des revenus anciens sous la région Ouest, ce qui peut être inexact. Le Type 2 préserverait la ligne ancienne de la région Ouest et créerait une nouvelle ligne de la région Est, permettant aux faits de s’associer à la bonne version au moment de l’événement. Le type 2 ajoute de la complexité : clés de substitution, joints sur des plages de dates, faits arrivant tardivement, rapports actuels contre historiques, et tables de dimensions plus grandes. Utilisez-le lorsque les rapports doivent refléter les attributus tels qu'ils étaient au moment de l'événement. Une réponse solide explique le besoin métier avant de choisir le type SCD.

Méthode — Gouvernance et flexibilité face à la simplicité de requête et aux performances

Un schéma en étoile sépare les faits des dimensions. Il convient lorsque l’on souhaite réutiliser les dimensions, garantir la cohérence des indicateurs et leur gouvernance, définir clairement la granularité et conserver une analyse flexible. Il réduit les duplications et facilite la gestion des évolutions des dimensions. Une table large et dénormalisée peut convenir à des analyses très fréquentes, à des variables de machine learning ou à des tableaux de bord pour lesquels la simplicité des requêtes et les performances sont prioritaires. Elle simplifie les jointures pour les utilisateurs, mais peut dupliquer les données et poser des problèmes de gouvernance si plusieurs tables définissent différemment les mêmes indicateurs. En pratique, je conserverais souvent des faits et des dimensions canoniques et fiables, puis je publierais des data marts ou des tables larges conçus pour des usages précis. La fondation de l’entrepôt de données doit rester digne de confiance, tandis que les modèles en aval s’adaptent aux besoins des utilisateurs. Le choix dépend du volume, des utilisateurs, du comportement de l’outil de BI, du coût, de la latence et de la fréquence d’évolution des définitions métier.

Méthode — Extraire -> stocker des données brutes -> transformer -> valider -> publier -> surveiller

Commencez par clarifier les exigences : actualité des données, volume de commandes, latence acceptable, contraintes de charge sur la base source, utilisateurs en aval et besoin éventuel de corriger l’historique. Une conception simple consiste à extraire les commandes de façon incrémentale avec updated_at ou la capture des changements, à conserver les données brutes dans un stockage objet ou une table brute, à les transformer dans des tables intermédiaires, puis à publier des tables de faits comme fact_orders et fact_order_items. L’orchestration peut utiliser Airflow, Dagster, dbt Cloud ou un service géré. Le pipeline doit être idempotent. Lorsqu’une date ou un lot est retraité, les données doivent être remplacées ou fusionnées de façon déterministe au lieu de créer des doublons. Gérez soigneusement les repères temporels et retraitez une fenêtre récente pour capturer les mises à jour tardives. Les validations comprennent le nombre de lignes, les clés primaires nulles, les identifiants de commande en double, les totaux de chiffre d’affaires, la répartition des statuts, l’actualité des données et le rapprochement avec la source. La supervision doit signaler les échecs, les variations inhabituelles de volume, les taux élevés de doublons et les retards de données. Documentez les responsables et les dépendances en aval.

Méthode — Une entrée identique et un redémarrage produisent le même résultat

Un pipeline idempotent peut être exécuté plusieurs fois avec la même entrée et produire le même résultat correct, sans doublons ni effets secondaires imprévus. Cette propriété est essentielle lorsque les pipelines échouent, redémarrent ou doivent retraiter des données. Par exemple, un pipeline non idempotent ajoute les commandes de la veille à chaque exécution. Après un redémarrage, le chiffre d’affaires est alors doublé. Une version idempotente remplace la partition cible, effectue une fusion par clé primaire ou écrit dans une table temporaire avant une permutation atomique. L’idempotence exige des clés claires, une stratégie de partitionnement, des transformations déterministes et une gestion prudente des effets secondaires. C’est un principe fondamental du data engineering en production, car la reprise après incident en dépend.

Méthode — Identifier -> classifier -> protéger -> communiquer -> migrer

Détectez automatiquement les changements de schéma au moyen d’un registre, de contrôles de métadonnées, de tests de contrat ou d’une validation à l’ingestion. Classez ensuite la modification : ajout ou suppression de colonne, renommage de champ, changement de type, de nullabilité ou de sens métier. L’ajout d’une colonne nullable est généralement sans risque. La suppression ou le renommage d’un champ et les changements de type peuvent casser les transformations et tableaux de bord en aval. Les changements sémantiques sont particulièrement dangereux, car le schéma peut rester valide alors que le sens des données a changé. Protégez le pipeline en conservant les données brutes, en vérifiant la compatibilité et en définissant des alertes et des contrats pour les sources critiques. En cas de rupture, coordonnez-vous avec les responsables de la source, mettez les transformations à jour, rechargez l’historique si nécessaire et communiquez l’impact en aval. Une réponse mature mentionne les contrats de données, le versionnement, la traçabilité, les tests et des responsabilités clairement définies afin d’éviter toute corruption silencieuse des analyses.

Méthode — Latence de décision contre complexité

Choisissez le streaming lorsque la faible latence crée une valeur réelle. C’est le cas, par exemple, pour la détection de fraude, les alertes opérationnelles, la personnalisation en temps réel, les mises à jour de stock, les indicateurs d’expériences en cours et les fonctionnalités produit qui exigent des événements récents. Le traitement par lots convient souvent mieux aux rapports quotidiens, à l’analyse historique, au rapprochement financier et aux transformations pour lesquelles une latence de quelques heures est acceptable. Il est plus simple à exploiter, plus facile à rejouer et généralement moins coûteux. La décision doit prendre en compte les besoins de fraîcheur, le volume d’événements, les garanties d’ordre, la gestion d’état, la tolérance aux pannes, l’expertise de l’équipe, les coûts et les consommateurs en aval. Le streaming n’est pas automatiquement préférable : il ajoute de la complexité liée aux doublons, aux événements tardifs, aux points de contrôle, à l’évolution du schéma et à la supervision. Une bonne réponse satisfait le besoin métier avec l’architecture la plus simple possible. Si des indicateurs quotidiens suffisent, il n’y a aucune raison de construire un système de streaming uniquement pour paraître plus sophistiqué.

Méthode — Événements -> flux -> enrichissement -> règles/modèle -> action -> stockage -> surveillance

Commencez par les exigences : volume d’événements, latence cible, type de décision antifraude, tolérance aux faux positifs et effet de la décision — blocage d’une transaction ou déclenchement d’un examen. Une architecture possible consiste à publier les événements de paiement dans Kafka ou Kinesis. Un processeur de flux les consomme, valide leur schéma, les déduplique par event_id, puis les enrichit avec des informations sur l’utilisateur, l’appareil, le commerçant et la vélocité historique avant d’appliquer des règles ou un modèle. Les événements à haut risque peuvent déclencher une décision automatisée, une file d’examen manuel ou une authentification renforcée. Les événements bruts et les décisions sont conservés durablement à des fins d’audit et d’entraînement. Les principaux enjeux d’ingénierie concernent les doublons, les événements désordonnés, la fraîcheur des variables, la taille du stockage d’état, les garanties de traitement « exactement une fois » ou « effectivement une fois », la contre-pression, les files de messages non traités, la relecture, le suivi de la latence et la gestion des versions des règles ou modèles. La qualité des données et la gouvernance sont essentielles, car les décisions antifraude affectent directement les clients. Consignez les motifs de chaque décision, surveillez le taux de faux positifs et prévoyez un mécanisme de retour arrière si une règle ou un modèle se comporte mal.

Méthode — Redistribution des données entre les partitions

Un bascule s'opère lorsque Spark doit redistribuer des données entre les partitions, généralement pour des opérations telles que groupBy, join, distinct, orderBy et repartition. Cela est coûteux car les données doivent se déplacer sur le réseau, être serialisées/désérialisées, écrites sur le disque et coordonnées entre les exécuteurs. Les bascules dominent souvent la durée de vie des travaux et peuvent entraîner des échecs lorsque les données sont biaisées ou que les données intermédiaires sont trop volumineuses. Une seule clé chaude peut envoyer trop de données vers une partition, créant des retardataires ou des erreurs de mémoire insuffisante. Les moyens de réduire le coût de la bascule incluent le filtrage précoce, la sélection de seules les colonnes nécessaires, la pré-agrégation, l'utilisation de jointures diffusées pour les petites tables, le partitionnement par clés de jointure, la salivation des clés biaisées, l'évitement des distinct/orderBy inutiles et le réglage du nombre de partitions. Une réponse qui relie le concept au débogage pratique : examine l'interface Spark, les étapes, la lecture/écriture de la bascule, le biais, le déversement, la durée des tâches et la mémoire de l'exécuteur.

Méthode — Identifier la phase -> réduire les données -> corriger l’asymétrie -> affiner les partitions -> éviter les opérations défavorables

Identifiez d’abord l’origine de la défaillance dans l’interface Spark UI ou les journaux : étape, opération, partition et exécuteur concernés. Une erreur OOM peut provenir d’une asymétrie des données, de jointures volumineuses, d’un appel à collect(), de partitions trop grandes, d’UDF Python inefficaces ou d’une mise en cache excessive. Réduisez le volume traité le plus tôt possible : filtrez les lignes, ne sélectionnez que les colonnes nécessaires, poussez les prédicats et évitez de lire des partitions inutiles. Examinez les jointures : diffusez une table suffisamment petite ; pour une clé très déséquilibrée, répartissez les valeurs dominantes ou traitez-les séparément. Si les partitions sont trop grandes, augmentez leur nombre ; si elles sont trop petites, regroupez-les de manière appropriée. Évitez collect() sur de gros volumes et privilégiez les fonctions natives aux UDF Python. Ne mettez les données en cache que si elles sont réutilisées et si la mémoire le permet. À l’écriture, évitez de produire trop de petits fichiers et choisissez un format colonnaire compressé comme Parquet. Si un réglage des ressources reste nécessaire, ajustez la mémoire et les cœurs des exécuteurs, le nombre de partitions après échange et la mémoire hors tas. Mais agrandir le cluster ne suffit pas toujours : corriger la répartition des données et le plan d’exécution est généralement plus durable.

Méthode — Stockage columnar, schéma, compression, poussée de prédicats

Parquet est un format de fichier columnar, efficace pour l’analyse car les requêtes lisent souvent uniquement un sous-ensemble de colonnes. Il prend en charge la compression, encode les types de données, stocke le schéma et permet la poussée de prédicats et l’élagage de colonnes dans de nombreux moteurs. CSV est un texte clair et linéaire. Il est lisible par l’homme et portable, mais il manque de types forts, peut être plus volumineux, est plus lent à parcourir, plus sujet aux erreurs avec les séparateurs/l’échappement, et ne peut pas ignorer efficacement les colonnes non pertinentes. Pour les lacs de données et les entrepôts de données, Parquet réduit généralement les coûts de stockage et améliore les performances des requêtes. CSV peut toujours être utile pour les exportations simples, les petits fichiers, ou l’interopérabilité, mais il n’est pas idéal comme format de stockage principal pour l’analyse.

Méthode — Fraîcheur -> complétude -> unicité -> validité -> réconciliation

Pour un pipeline critique de chiffre d’affaires, j’ajouterais des contrôles sur la fraîcheur des données, le nombre de lignes, les clés primaires nulles, les identifiants de transaction en double, la validité des statuts et devises, les montants négatifs inattendus, les plages de dates admises et l’intégrité référentielle entre commandes, paiements, remboursements et clients. J’ajouterais aussi des contrôles de rapprochement : comparer le chiffre d’affaires total au système de paiement source, aux rapports financiers ou à la précédente exécution du pipeline. Je surveillerais les variations quotidiennes et hebdomadaires à l’aide de seuils qui tiennent compte de la saisonnalité et des événements connus. Les règles métier sont tout aussi importantes : les commandes annulées ne doivent pas être comptabilisées, les remboursements doivent réduire le chiffre d’affaires net, les transactions de test doivent être exclues et la conversion des devises doit employer le bon taux. Les alertes doivent permettre d’agir, être envoyées à un responsable identifié et fournir le contexte utile : contrôle ayant échoué, table concernée, gravité, dépendances en aval et procédure recommandée. Un excès d’alertes inutiles finira par être ignoré.

Méthode — Évaluer l’impact → comparer les versions → examiner la traçabilité → limiter les conséquences → identifier la cause racine

Commencez par évaluer l’impact : quels tableaux de bord, indicateurs, utilisateurs, périodes et décisions sont concernés ? Déterminez si la valeur est erronée ou si le déploiement a corrigé une erreur antérieure. Comparez le nouveau résultat à la version précédente, table par table et partition par partition, en examinant le nombre de lignes, le nombre de valeurs distinctes, les totaux des indicateurs et les segments clés. Utilisez la traçabilité des données pour repérer les changements en amont. Contrôlez les modifications du code et du schéma, les filtres, les jointures, la déduplication et la logique de dates. Si l’indicateur est incorrect et affecte les utilisateurs métier, limitez rapidement les conséquences : revenez à la transformation précédente, restaurez une ancienne version de la table, désactivez le tableau de bord ou affichez un avertissement. Recherchez ensuite la cause racine et rechargez les données corrigées si nécessaire. La communication est essentielle. Informez les parties prenantes de ce qui a changé, des éléments concernés, du niveau de confiance, du délai de correction prévu et de la nécessité éventuelle de réexaminer des décisions passées.

Méthode — Instrumentation -> ingestion -> stockage -> traitement -> modélisation -> fourniture -> gouvernance

Commencez par les exigences : volume d’événements, latence, consommateurs, durée de conservation, évolution du schéma, confidentialité et fiabilité. Les événements d’usage produit peuvent alimenter des tableaux de bord, des expérimentations, la personnalisation et des fonctionnalités de machine learning. Les applications clientes émettent des événements au moyen d’un SDK avec un nom d’événement, un identifiant utilisateur, un identifiant de session, un horodatage, des propriétés, la version de l’application, la plateforme et un identifiant anonyme. Ces événements passent par une API d’ingestion ou un collecteur, puis par un flux durable comme Kafka, Kinesis ou Pub/Sub. Les données brutes sont conservées dans un stockage objet pour pouvoir être rejouées, puis chargées dans un entrepôt ou un lac à des fins d’analyse. Le traitement comprend la validation du schéma, la déduplication, le filtrage des robots et du trafic interne, la sessionisation, la résolution d’identité et la transformation en tables modélisées comme fact_events, fact_sessions et dim_users, ainsi qu’en tables dédiées aux différents produits. Les traitements par lots et en continu peuvent coexister selon les besoins de fraîcheur. Pour la qualité et la gouvernance, prévoyez des contrats d’événements, un registre de schémas, la gestion des données personnelles et du consentement, la traçabilité, des responsables identifiés, des contrôles de fraîcheur, des alertes sur les anomalies de volume et de la documentation. Les données peuvent ensuite alimenter les tableaux de bord BI, l’analyse des expérimentations, le reverse ETL et les dépôts de fonctionnalités. Les principaux compromis concernent le coût du temps réel par rapport au traitement par lots, la rigidité du schéma, la durée de conservation des données brutes, la complexité de la résolution d’identité et la répartition de la logique entre ingestion et transformation.

Méthode — Cohérence hors ligne/en ligne -> définitions de fonctionnalités -> fraîcheur -> fourniture -> surveillance

Un dépôt de fonctionnalités doit fournir des variables réutilisables et fiables pour l’entraînement comme pour l’inférence. Les exigences portent sur leur définition, leur cohérence temporelle, les données d’entraînement hors ligne, la mise à disposition en ligne à faible latence, la fraîcheur, le contrôle d’accès et la supervision. Les variables hors ligne peuvent être stockées dans un entrepôt ou un lac, partitionnées par date et par entité. Les variables en ligne peuvent être servies depuis un magasin clé-valeur à faible latence. Un registre conserve les métadonnées : nom, responsable, clé d’entité, logique de transformation, SLA de fraîcheur, tables sources et description. La cohérence à un instant T est essentielle. Les données d’entraînement doivent employer uniquement les valeurs disponibles au moment de la prédiction, jamais des informations futures. La même logique de transformation doit être réutilisée hors ligne et en ligne lorsque c’est possible ; si des pipelines distincts sont nécessaires, leur équivalence doit être testée rigoureusement. La supervision doit couvrir la fraîcheur, les taux de valeurs nulles, la dérive des distributions, la latence du service en ligne, l’écart entre entraînement et production et l’impact sur les modèles en aval. La gouvernance comprend la protection des données personnelles, la traçabilité, le retrait progressif des variables et l’attribution claire des responsabilités.

Méthode — Impact -> triage -> atténuation -> racine profonde -> prévention

Choisissez un incident ayant eu un impact réel : données manquantes, indicateurs erronés, pipeline en retard, enregistrements en double, tableau de bord défectueux, variables de modèle incorrectes ou effet sur un produit en aval. Commencez par identifier les personnes touchées et expliquer pourquoi l’incident était important. Décrivez ensuite votre diagnostic : journaux, état de l’orchestrateur, fraîcheur des sources, déploiements récents, changements de schéma, nombre de lignes, partitions, traçabilité et dépendances en aval. Expliquez comment vous avez limité l’impact : réexécution, retour arrière, correctif, reprise des données historiques ou avertissement des parties prenantes. Les meilleures réponses abordent aussi la prévention. Avez-vous ajouté des contrôles de qualité, des alertes, des mécanismes de nouvelle tentative, des contrats de schéma, des écritures idempotentes, des procédures opérationnelles, de la traçabilité ou de meilleurs contrôles de déploiement ? Évitez de blâmer les équipes en amont : montrez que vous assumez la fiabilité du système et la communication. Terminez par ce que vous avez appris et par les changements apportés ensuite à votre façon de travailler.

Méthode — Clarifier -> reproduire -> remonter la traçabilité -> résoudre -> documenter

Commencez par préciser ce qui paraît incorrect : quel indicateur, quelle table, quelle période, quel tableau de bord, quels filtres, quelle valeur attendue et quel raisonnement métier ? L’affirmation « les données sont erronées » doit être transformée en problème reproductible. Comparez ensuite la requête de l’analyste ou le tableau de bord avec les tables sources et les définitions des modèles. Vérifiez la granularité, les filtres, les jointures, les fuseaux horaires, la fraîcheur, la définition des indicateurs et les changements récents. Utilisez la traçabilité pour remonter les dépendances. Si les données sont incorrectes, corrigez-les et communiquez l’impact. Si elles sont exactes mais que leur définition diffère de l’attente, alignez les parties prenantes sur une définition commune et documentez-la. Si une incertitude subsiste, précisez ce qui est connu, ce qui reste à vérifier et la date du prochain point. La relation compte : les analystes utilisent la plateforme de données comme un produit, et la confiance repose sur des réponses rapides, claires et étayées.

Méthode — Impact -> fiabilité -> urgence -> dépendances -> levier

Vous priorisez en fonction de l’impact métier, du risque de fiabilité, de l’urgence, des dépendances en aval et du levier. Une faille dans la chaîne de revenus ou un problème de conformité l’emporte généralement sur un modèle de tableau de bord agréable à avoir. Une amélioration de la plateforme peut l’emporter sur une demande ponctuelle si elle débloque de nombreuses équipes. Je distingue également les incidents urgents, le travail stratégique sur la plateforme, les demandes des parties prenantes, la dette technique et le travail opérationnel. Si l’équipe ne traite que des tickets, la fiabilité et la qualité de la plateforme déclinent. Si l’équipe ne construit que des abstractions de plateforme, les équipes commerciales peuvent être bloquées. Un processus de priorisation solide inclut la responsabilité, les accords de service, les niveaux de gravité, l’alignement sur la feuille de route et des compromis transparents. Je communiquerais ce qui est fait, ce qui est reporté, pourquoi, et quel risque cela génère.