Ce qui entre vraiment en premier dans le modèle open source, c’est la question de la chaîne d’approvisionnement.

Une fois qu’un tel sujet est écrit comme « scellé », l’attention sera attirée sur une image trop dramatique. Les changements les plus courants dans le projet sont moins dramatiques : la source de téléchargement publique devient instable, des sites miroirs commencent à apparaître, une certaine version est retirée des étagères, le rythme des mises à jour continues est interrompu et la chaîne de raisonnement entre les mains de l’équipe doit soudainement se maintenir.

La couche d’hébergement prend la pression en premier

Plus on discute du modèle open source, plus il est facile de voir clairement une chose : ce qui peut être directement touché par les politiques, les contrôles à l’exportation et les règles de la plateforme, ce ne sont souvent pas les documents pondérés qui ont été distribués, mais l’hébergement public, l’inférence en ligne, la distribution des versions et les entrées par défaut.

Cela signifie que même s’il semble « scellé », le chemin qui est réellement coupé est souvent le chemin le plus facile. Ce qui était autrefois un simple processus consistant à extraire une URL, à configurer une interface d’hébergement et à l’appeler une fois s’est soudainement transformé en recherche d’image, ajout d’une signature, vérification du hachage, vérification de la licence et confirmation de la version de restauration. Les actions peuvent paraître modestes, mais lorsqu’elles sont connectées, elles forment une chaîne d’approvisionnement complète.

Une fois la version forkée, le nom n’explique plus le problème.

La partie la plus difficile du modèle open source n’est jamais « s’il en existe un ». Une fois que le poids se répartit sur plusieurs images, plusieurs entrepôts organisationnels et plusieurs branches de réglage fin, différents comportements se développeront sous le même nom.

A l’heure actuelle, il ne suffit plus de discuter « si le modèle est toujours là ». La question la plus difficile est la suivante : laquelle est la ligne principale, laquelle n’est qu’une image miroir, laquelle a été entraînée deux fois et laquelle conserve toujours le comportement de raisonnement d’origine. Le nom peut toujours désigner le même projet, mais les résultats ont commencé à diverger. À ce stade, si l’équipe considère toujours le « même nom » comme « la même chose », les résultats en ligne s’écarteront tôt ou tard.

C’est également la plus grande différence entre les modèles open source et les API fermées. L’API source fermée est déconnectée et les performances sont très simples ; le modèle open source est divisé et, en apparence, le service fonctionne toujours, mais en coulisses, la version, les dépendances et les limites de comportement ont été modifiées. Ce qui est vraiment inquiétant, ce n’est souvent pas l’échec, mais « cela semble quand même fonctionner ».

Ce qui doit vraiment être corrigé, c’est la source, la restauration et la récurrence hors ligne.

Lorsque ce type de changement arrive au projet, la première chose à compenser n’est pas l’émotion, mais trois choses : la source, le rollback et la récurrence hors ligne.

La source doit être traçable jusqu’à des entrepôts spécifiques, des soumissions spécifiques et des documents de poids spécifiques. Le rollback doit pouvoir revenir à la version précédente du comportement, pas seulement à un nom. La reproduction hors ligne doit pouvoir exécuter à nouveau la même série d’expériences lorsque le réseau tremble, que le miroir est perdu ou que le paquet en amont est supprimé.

De nombreuses équipes ont généralement le sentiment que ces choses sont loin d’elles. Ce n’est qu’un jour qu’une mise à jour en amont modifie le style de sortie, ou qu’une certaine synchronisation d’image est lente, qu’ils découvrent que le problème ne réside pas du tout dans la capacité du modèle, mais dans la chaîne de dépendances qui n’est pas gérée comme un citoyen de premier ordre. Plus le modèle est open source, plus cela est évident. Car ce qu’apporte l’open source, ce n’est pas une « entrée gratuite » toujours stable, mais une chaîne d’approvisionnement de plus en plus longue.

La partie la plus physique n’est généralement pas le corps du modèle.

Lorsqu’il s’agit d’un environnement de production, le problème le plus probable n’est généralement pas l’ontologie de poids, mais l’entrée par défaut, les mises à jour automatiques et les dépendances implicites.

Si une équipe considère un certain portail en ligne comme la seule source, elle peut encore l’appeler aujourd’hui, mais elle devra peut-être temporairement trouver un remplaçant demain ; s’il considère une station miroir comme la vérité par défaut, la dérive des versions se faufilera discrètement dans la formation et l’évaluation ; si le rythme de mise à jour est trop serré, la stabilité du comportement d’aujourd’hui n’est pas claire et la nouvelle version de demain sera en ligne.

Ce genre de problème ressemble donc à de la politique internationale, mais lorsqu’il s’agit d’ingénierie, il ressemble davantage à la gouvernance de la chaîne d’approvisionnement. Qui contrôle l’entrée, qui est responsable de la signature, qui définit la restauration, qui enregistre l’ancienne version et qui peut reconstruire hors ligne, telles sont les limites qui continueront d’affecter la livraison. Une fois le modèle lui-même rendu public, l’espace laissé aux actions extérieures deviendra plus petit ; l’espace laissé à l’équipe pour inventer ses propres leçons deviendra plus grand.

La question de savoir si le modèle open source sera « scellé » est une question un peu étroite. Un jugement plus réaliste serait le suivant : plus le code source est open source, plus il est difficile de le maintenir en place par une seule action ; mais plus il est open source, plus il doit gérer les versions, les sources, les restaurations et les récurrences hors ligne. Si cette chaîne d’approvisionnement n’est pas maîtrisée, toute fluctuation externe sera amplifiée en un accident qui ressemble à un « accident modèle ».