Socio-Technical Anti-Patterns in Building ML-Enabled Software: Insights from Leaders on the Forefront

Résumé technique : Anti-patterns socio-techniques dans la construction de logiciels dotés de l'apprentissage automatique (ML)

Énoncé du problème
Malgré le succès économique et l'omniprésence des logiciels dotés d'apprentissage automatique (ML), un écart important subsiste entre le développement de modèles et leur mise en production réussie. Alors que la littérature existante traite abondamment des obstacles techniques tels que les tests, les pipelines et l'automatisation (MLOps), il existe une rareté des recherches se concentrant sur les défis socio-techniques inhérents à la construction de ces systèmes. La construction de logiciels de ML est intrinsèquement une entreprise impliquant plusieurs personnes et plusieurs équipes, pourtant les études négligent souvent les barrières organisationnelles, de gestion et de communication qui empêchent les modèles d'atteindre la production. Cet article postule que de nombreux échecs ne sont pas technologiques mais découlent de silos organisationnels, de vides de leadership et de problèmes de communication, faisant écho aux observations selon lesquelles « le MLOps est un problème organisationnel ».

Méthodologie
Pour étudier ces défis socio-techniques, les auteurs ont mené la plus grande étude empirique qualitative dans ce domaine à ce jour. La recherche a utilisé l'Analyse Thématique Réflexive (ATR), une méthode permettant aux chercheurs de s'engager analytiquement avec les données plutôt que de simplement les résumer.

• Source de données : L'étude a analysé 73 vidéos (totalisant 66 heures de contenu) de l'MLOps.community, un groupe d'intérêt mondial comptant plus de 11 000 membres. Ce corpus comprend des conférences, des rencontres (meetups) et des sessions de discussion présentant des praticiens issus de divers rôles, tailles d'entreprises et zones géographiques.
• Stratégie d'échantillonnage : À partir d'un pool initial de 210 vidéos, les auteurs ont appliqué un processus de sélection en deux phases :
  1. Phase d'induction : Filtrage initial basé sur le mot-clé « équipe » pour identifier les discussions socio-techniques, suivi d'une familiarisation manuelle et d'un codage.
  2. Phase de déduction et de raffinement : Utilisation des codes extraits pour identifier les passages pertinents dans les vidéos restantes, affinage des thèmes et extraction des recommandations.
• Démographie : Les intervenants comprenaient des gestionnaires (31,3 %), des leaders (27,6 %) et des data scientists/ingénieurs (22,7 %), représentant des entreprises allant de startups à de grandes entreprises à travers l'Amérique du Nord, l'Europe et d'autres continents.
• Analyse : Les auteurs ont développé les thèmes de manière itérative, structurant finalement les résultats en anti-patterns (symptômes), causes et recommandations.

Principales contributions
La principale contribution de l'article est l'identification et l'analyse de 17 anti-patterns socio-techniques ancrés dans des problèmes organisationnels et de gestion plutôt que dans des déficiences purement techniques. L'étude contextualise ces résultats avec des recherches antérieures (ex. : Nahar et al., Kim et al.) pour valider les résultats existants et mettre en lumière de nouvelles perspectives, particulièrement du point de vue de la gestion.

Résultats clés : Les 17 anti-patterns
Les résultats sont catégorisés en trois domaines organisationnels principaux :

1. Silos organisationnels

• Intégration Modèle vers Produit :
  • AP1 (Cycles de mise en production longs) : Le couplage serré entre les équipes de modèles et de produits crée des goulots d'étranglement.
  • AP2 (Tension entre les équipes) : Des plaintes mutuelles apparaissent en raison d'un manque de compréhension entre les data scientists et les ingénieurs logiciels.
  • AP3 (Data scientists bloqués) : Les data scientists sont détournés de la recherche vers des tâches de production en raison de frictions lors des transferts.
  • Causes : Choc des cultures/outils (C1) et manque de compétences en ingénierie au sein des équipes de data science (C2).
• Intégration Producteur de données vers Consommateur :
  • AP4 (La demande de données est difficile) : Les producteurs de données résistent à l'exposition des données par manque de valeur perçue ou par conflits d'objectifs.
  • AP5 (Couplage technique serré) : Des processus de transfert peu clairs entraînent des dépendances de code/données entre les équipes.
  • AP6 (Disponibilité partielle des données) : Les données d'entraînement diffèrent des données de production, provoquant une dégradation du modèle.
  • Causes : Manque de sensibilisation/objectifs communs (C3) et manque de documentation/responsabilités (C4).

2. Déficits de communication

• Développement redondant :
  • AP7 (Caractéristiques non découvrables) : Les équipes construisent de manière indépendante des caractéristiques (features) sémantiquement similaires.
  • AP8 (Infrastructure ML redondante) : Des pipelines et des outils dupliqués sont construits par différentes équipes.
  • AP9 (Shadow IT) : Les équipes contournent les fournisseurs d'infrastructure centraux, créant des risques de sécurité.
  • Cause : Manque d'intersections, de documentation et de confiance entre les équipes (C5).
• Management vs Data Science :
  • AP10 (Burnout) : Les data scientists ont le sentiment de ne produire aucune valeur tangible à cause d'itérations sans fin.
  • AP11 (Tension avec le management) : Des conflits surgissent de l'alignement défectueux des attentes concernant la valeur métier et l'incertitude de la recherche.
  • Causes : Absence de processus de data science (C6) et décalages de communication entre les parties prenantes techniques et non techniques (C7).

3. Vide de leadership

• Recrutement « Tête brûlée » (Headless-Chicken-Hiring) :
  • AP12 (Personnel aux compétences insuffisantes) : Recruter des data scientists pour des tâches très orientées ingénierie (ex. : pipelines).
  • AP13 (Pas de produit pour les data scientists) : Recruter pour un cas d'usage spécifique qui disparaît, laissant l'employé sans rôle.
  • Causes : Rôles/titres flous (C8), recrutement non éduqué (C9) et pénurie de compétences sur le marché (C10).
• Développement piloté par le CV (Résumé-Driven Development) :
  • AP14 (Inadéquation outils/objectifs) : Les choix technologiques sont dictés par la construction du CV individuel plutôt que par les besoins métier.
  • Causes : Data scientists déconnectés de la valeur métier (C11) et absence de décideurs (C12).
• Création de produits pilotée par le Hype (Hype-Driven Product Creation) :
  • AP15 (Coincé dans les PoC) : Les organisations restent dans l'enfer des preuves de concept (PoC) sans jamais passer en production.
  • AP16 (Tout nécessite du ML) : La croyance que le ML est la solution à tous les problèmes.
  • AP17 (Produits irréalisables) : Projets lancés sans les données ou les talents nécessaires.
  • Causes : Absence de stratégie organisationnelle (C13), manque de connaissances en ML de la part du management (C14), manque de traduction entre les parties prenantes (C15) et absence de métriques de production (C16).

Recommandations
L'article suggère que si les outils (ex. : registres de modèles, Feature Stores) peuvent atténuer les symptômes, les causes profondes nécessitent un changement organisationnel. Les recommandations incluent :

• Restructurer les équipes pour qu'elles soient transversales (cross-functional).
• Associer des data scientists à des ingénieurs logiciels pour les revues de code.
• Établir des plateformes centrales comme contrats pour la qualité des données et la documentation.
• Mettre en œuvre des processus de développement rigoureux et une documentation adaptée au ML.
• Recruter pour des compétences spécifiques plutôt que pour des titres ambigus.
• Créer des processus rigoureux pour valider les cas d'usage et la disponibilité des données avant le début du développement.

Signification et affirmations
Les auteurs affirment que cette étude offre une vue holistique des défis du développement ML en s'appuyant sur un ensemble de données unique de discussions de praticiens, incluant des perspectives de leaders et de gestionnaires souvent absents des études centrées sur les développeurs. En formulant ces problèmes sous forme d'anti-patterns, l'article vise à sensibiliser au fait que les problèmes socio-techniques sont souvent la cause profonde des échecs de production, fréquemment diagnostiqués à tort comme de la dette technique.

L'étude valide et étend les recherches antérieures (ex. : Nahar et al., Kim et al., Granlund et al.) en confirmant l'existence de silos organisationnels et de chocs culturels, tout en ajoutant de nouvelles dimensions concernant les vides de leadership et les pratiques de recrutement. Les auteurs notent modestement que bien que leurs conclusions soient généralisables grâce à un échantillon diversifié, des recherches supplémentaires sont nécessaires pour déterminer si ces anti-patterns sont spécifiques au ML ou s'ils sont des artefacts de défis socio-techniques plus larges de l'ingénierie logicielle. En fin de compte, l'article sert de guide aux praticiens et aux gestionnaires pour identifier et traiter les barrières non techniques à une adoption réussie du ML.