Litige sur le code de Google Artemis : Minitap affirme que le crédit de mobile-use a été supprimé

Google fait face à un litige sur l’attribution en open source après que Minitap a identifié du code et des prompts présumément copiés dans Artemis, le projet d’automatisation Android récemment rendu public par Google.

Le litige sur le code de Google Artemis concerne davantage que des idées similaires entre deux agents mobiles. Minitap affirme que des détails d’implémentation identiques sont apparus dans Artemis sans crédit visible. L’entreprise a également présenté un historique de dépôt qui semble montrer ses développeurs comme auteurs avant que leurs noms ne disparaissent.

Cet historique constitue le cœur du conflit. Minitap a publié mobile-use sous licence Apache License 2.0, autorisant la modification et la réutilisation commerciale dans des conditions définies. La startup s’oppose à une réutilisation présumée sans provenance claire, et non au fait que Google développe un outil concurrent.

Les éléments publics ont déjà évolué. Au 13 septembre, le README d’Artemis indique que le projet inclut du code source développé par Minitap. Cette reconnaissance était absente de la version décrite dans la publication de Minitap du 11 septembre.

Le crédit actuellement accordé par Google répond au grief le plus visible, mais ne résout pas toutes les questions. Les enjeux restants concernent les composants provenant initialement de l’amont, le moment où l’attribution a disparu, et le respect de l’ensemble des conditions de licence applicables.

Ce que Minitap a trouvé dans Google Artemis

Les éléments les plus solides avancés par Minitap sont la combinaison de code correspondant, de prompts correspondants et d’une liste d’auteurs antérieure, plutôt qu’une seule idée architecturale partagée.

Artemis et mobile-use permettent tous deux à des agents d’IA d’utiliser des téléphones via des instructions en langage naturel. Cette similitude générale prouve peu de choses, car de nombreux agents mobiles utilisent des captures d’écran, des données d’accessibilité, des boucles de planification et des outils de contrôle d’appareils.

Les accusations de Minitap deviennent plus précises au niveau de l’implémentation. Son récit publié identifie une logique de connexion Android qui, selon l’entreprise, correspond à du code précédemment publié dans mobile-use.

L’entreprise met également en avant un agent appelé Hopper. Dans le système de Minitap, Hopper recherche, dans de grands lots d’historique d’écrans et d’interactions, les informations pertinentes pour la tâche en cours.

Minitap affirme qu’Artemis contenait le même prompt Hopper, avec des formulations et des exemples correspondants. L’identité des prompts compte, car des instructions détaillées peuvent faire office de code source au sein d’un système d’agents.

Une instruction générique comme « rechercher dans l’historique » pourrait émerger indépendamment. Un prompt étendu présentant une structure, des exemples, des noms, des commentaires et un comportement de nettoyage identiques rend l’argument de la coïncidence plus difficile à soutenir.

L’entreprise évoque également un exemple de messagerie. Elle affirme que les deux projets utilisaient les mêmes noms illustratifs, commentaires et séquence d’opérations.

Les exemples peuvent révéler une provenance lorsqu’ils préservent des choix arbitraires que la fonctionnalité n’exige pas. Deux implémentations peuvent se connecter indépendamment à Android Debug Bridge, communément appelé ADB. Il est moins probable qu’elles choisissent indépendamment les mêmes détails fictifs tout au long d’un exemple plus long.

Minitap affirme en outre que les deux projets partageaient un bug de gestion de fichiers. Selon sa publication, Artemis a ensuite corrigé ce comportement.

Un défaut partagé peut constituer un élément probant important, car les développeurs copient généralement le comportement voulu, et non les modes d’échec accidentels. Toutefois, les lecteurs ne peuvent pas considérer cet indice comme un jugement technique définitif sans comparaison complète, spécifique aux versions concernées.

L’élément le plus important concerne les métadonnées du package. Minitap affirme qu’un ancien fichier de package d’Artemis mentionnait Pierre-Louis Favreau, Jean-Pierre Lo et Nicolas Dehandschoewercker comme auteurs.

Ces noms correspondent à des contributeurs associés au travail de Minitap sur mobile-use. Minitap affirme qu’une révision ultérieure les a remplacés par un autre auteur tout en laissant par ailleurs le fichier concerné inchangé.

L’entreprise relie ce remplacement à un force push effectué en août. Un force push réécrit l’historique visible d’une branche Git, ce qui peut supprimer des commits de la branche sans effacer instantanément chaque objet sous-jacent ou copie externe.

Cette distinction est importante. Les force pushes sont courants lors du nettoyage d’un dépôt, mais ils deviennent significatifs lorsqu’un commit réécrit contenait des informations de provenance pertinentes dans le cadre d’un litige ultérieur.

Minitap affirme avoir récupéré la révision antérieure via l’historique Git, bien que le commit ne soit plus rattaché à la branche principale. L’accusation repose donc en partie sur des éléments historiques du dépôt, et non uniquement sur les fichiers actuels.

Aucun tribunal, régulateur ou organisme indépendant d’audit de code n’a statué sur ces allégations. Les éléments disponibles justifient un examen attentif, mais l’accusation reste le récit documenté de Minitap.

Google n’a pas expliqué publiquement le remplacement des auteurs dans les documents examinés pour cet article. L’entreprise n’a pas non plus fourni de déclaration fichier par fichier décrivant les composants d’Artemis dérivés de mobile-use.

Cette absence d’explication empêche une reconstitution complète. Elle n’efface pas les affirmations de similitudes visibles ni les métadonnées antérieures décrites par Minitap.

Le changement immédiat reste néanmoins concret. Une petite équipe open source a publiquement contesté un dépôt Google, et le README actuel de Google reconnaît désormais du code développé par Minitap.

Pourquoi le litige sur le code de Google Artemis est important

La pression s’exerce sur Google parce que sa crédibilité institutionnelle rend une provenance irréprochable plus importante, et non moins importante.

Le développement open source repose sur le fait que l’autorisation et l’attribution remplissent des fonctions distinctes. Une licence permissive accorde aux développeurs en aval une large liberté, tandis que les registres de provenance identifient les créateurs du travail sous-jacent.

Minitap affirme explicitement que la réutilisation est bienvenue. Son objection est que les développeurs ne devraient pas découvrir un projet Google apparemment indépendant sans apprendre qu’une partie du code provient de mobile-use.

Cette préoccupation dépasse la reconnaissance. La provenance aide les responsables de maintenance à retracer les défauts de sécurité, les décisions architecturales, les correctifs en amont et les modifications incompatibles.

Si les utilisateurs en aval ne peuvent pas identifier la source d’un composant, ils peuvent signaler des bugs à la mauvaise équipe. Ils peuvent également manquer des correctifs déjà disponibles dans le projet en amont.

Les développeurs qui évaluent Artemis doivent savoir quelles parties Google maintient indépendamment. Ils doivent aussi savoir où commence le comportement hérité et où les modifications de Google divergent.

Ces informations influencent la diligence technique. Une équipe adoptant un agent pour les tests d’appareils doit évaluer la responsabilité de la maintenance, les dépendances, les licences et la fiabilité des affirmations relatives aux benchmarks.

Le nom Google suscite des attentes car l’entreprise publie des guides open source détaillés. Sa documentation indique que les revues de publication doivent vérifier les en-têtes de licence et les autres éléments requis avant que le code ne soit rendu public.

Google assure également la maintenance d’Android, Chromium, TensorFlow, Kubernetes et de nombreux autres projets largement utilisés. Ses équipes demandent régulièrement aux contributeurs externes et aux entreprises de suivre des processus de licence structurés.

Une faille de provenance au sein d’une organisation Google revêt donc une importance symbolique. Les responsables de maintenance indépendants attendent des plus grandes entreprises de logiciels qu’elles incarnent les pratiques qu’elles exigent ailleurs.

Le déséquilibre entre les parties accentue cette pression. Une startup peut publier des recherches et du code utiles, mais une organisation plus grande peut attirer davantage d’attention après avoir publié un système similaire.

Les résultats de recherche, la distribution sur les réseaux sociaux et la notoriété de la marque peuvent rapidement associer une approche à l’éditeur le plus important. L’absence d’attribution peut alors masquer la contribution de la plus petite équipe, même lorsque le code reste disponible.

C’est le principal renversement de cette affaire. L’open source a donné à Google l’autorisation de s’appuyer sur un travail partagé, mais cette même ouverture a exposé les éléments étayant la plainte de Minitap.

Les dépôts Git publics préservent les diffs, forks, pages mises en cache, fichiers de package et commits détachés. Réécrire une branche ne peut garantir que les anciens enregistrements d’auteurs disparaissent de chaque copie.

La controverse concerne également les contributeurs au-delà de Minitap. Les développeurs décident en partie de publier des travaux précieux en observant comment les organisations en aval traitent l’origine et le crédit.

Les licences permissives encouragent l’adoption parce qu’elles imposent moins de restrictions commerciales. Ce modèle reste durable lorsque les utilisateurs respectent les conditions limitées qui subsistent et communiquent honnêtement sur la provenance.

Si les petites équipes pensent que des publications permissives seront absorbées sans reconnaissance, elles pourraient retarder leur publication. D’autres pourraient choisir des conditions de copyleft plus fortes ou garder privés des composants stratégiquement importants.

Aucune de ces réponses ne profite automatiquement aux utilisateurs. L’automatisation mobile progresse lorsque les chercheurs peuvent inspecter les agents, reproduire les résultats, comparer les stratégies et apporter des correctifs au-delà des frontières organisationnelles.

La leçon n’est pas que les entreprises devraient éviter le code open source. Elle est que les processus internes de publication doivent préserver l’historique en amont avant que le code n’entre dans un dépôt d’entreprise soigné.

Ce processus devrait inclure des inventaires de sources, des contrôles automatisés de similarité, des registres de dépendances, une revue des licences et une vérification humaine. Une base de connaissances d’ingénierie consultable peut également maintenir le lien entre la provenance et les décisions de conception.

Les responsables de dépôts devraient documenter les fichiers copiés et les adaptations substantielles avant le lancement. Ajouter une attribution après un litige vaut mieux que la laisser absente, mais cela ne peut remplacer un dossier de développement clair.

Google est donc incité à expliquer la séquence des événements, et non simplement à conserver la nouvelle phrase. L’organisation doit montrer si l’omission constituait une erreur de publication isolée ou révélait un processus de provenance plus fragile.

Le crédit actuel modifie le récit, mais pas l’historique

Le README actuel de Google reconnaît Minitap, faisant passer la controverse d’une omission non résolue à un litige sur la manière et la raison pour lesquelles l’attribution a disparu.

Le dépôt Artemis actuel décrit un système d’automatisation Android construit par l’équipe Pixel Test Engineering Fusion de Google. Il présente deux profils d’exécution et des intégrations pour les assistants de codage IA.

Le mode Flash utilise une boucle réactive d’observation et d’action. Artemis indique qu’il nécessite généralement trois à cinq secondes par étape tout en compressant l’historique des interactions plus anciennes.

Le mode Pro utilise des composants de planification et de vérification. Il contrôle les actions proposées par rapport aux données actuelles de l’interface avant leur exécution et prend en charge des flux de travail de test plus longs.

Le dépôt décrit également l’intégration avec Model Context Protocol. MCP est une interface standard par laquelle des assistants IA compatibles peuvent appeler des outils externes et recevoir des résultats structurés.

Ces fonctionnalités montrent qu’Artemis n’est pas nécessairement une copie inchangée de mobile-use. Un projet en aval peut combiner des composants hérités avec une ingénierie originale substantielle.

Ce point ne contredit pas la plainte de Minitap. Les questions d’attribution s’appliquent aux parties copiées, même lorsqu’un système dérivé ajoute de nouvelles interfaces, des contrôles de sécurité, des modes d’exécution ou des diagnostics.

Le README actuel inclut désormais une déclaration directe dans sa section de licence : le projet contient du code source développé par Minitap. La phrase renvoie au dépôt mobile-use.

Il s’agit d’une correction importante. Un développeur qui accède aujourd’hui au projet peut identifier Minitap comme source en amont sans mener une recherche médico-légale.

Cependant, cette déclaration reste générale. Elle n’identifie pas les fichiers, prompts, agents ou composants architecturaux provenant de mobile-use.

Elle n’explique pas non plus les métadonnées antérieures des auteurs. Si la reconstitution de Minitap est exacte, trois contributeurs nommés figuraient dans une configuration de paquet avant d’être remplacés.

La mention du projet et la paternité individuelle sont liées, mais distinctes. La reconnaissance d’une entreprise peut identifier l’organisation d’origine tout en laissant incertaine l’historique des contributions de développeurs précis.

Une réponse détaillée pourrait dissiper une grande part de l’incertitude. Google pourrait publier la séquence de commits concernée, expliquer le force push et associer les composants hérités à leurs révisions d’origine.

L’entreprise pourrait également préciser si le changement d’auteur était accidentel, relevait d’une migration de dépôt ou constituait une normalisation intentionnelle des métadonnées. Sans cette explication, les observateurs extérieurs doivent déduire l’intention à partir d’un historique incomplet.

L’intention compte pour la confiance du public, mais le respect des licences dépend souvent de pratiques concrètes de distribution. Une omission négligente et une suppression délibérée peuvent produire des fichiers similaires tout en révélant des défaillances organisationnelles différentes.

La correction actuelle complique aussi les titres simplistes affirmant que Google n’accorde actuellement aucun crédit. Cette description semble obsolète au 13 septembre.

Le cadrage exact est chronologique. Minitap affirme qu’Artemis ne comportait aucune mention lorsqu’il a documenté les similitudes, tandis que le dépôt actif crédite désormais le code source développé par Minitap.

Les lecteurs doivent également distinguer Google de chaque contributeur utilisant un dépôt hébergé par Google. Les dépôts publics peuvent impliquer des équipes, des sous-traitants, des projets transférés et des mainteneurs individuels suivant des processus de revue différents.

Le dépôt identifie une équipe Google, ce qui fait de l’entreprise un sujet légitime d’examen. Toutefois, les éléments examinés ici ne permettent pas d’établir qui a approuvé ou supprimé les noms antérieurs.

Cette incertitude explique pourquoi le différend autour du code de Google Artemis doit rester centré sur les documents et les processus. Les spéculations sur des motivations personnelles ajoutent de la tension sans améliorer la vérification.

La reconnaissance actuelle renforce une partie de la position de Minitap. Le dépôt de Google reconnaît désormais explicitement que du code de Minitap est présent.

Elle ne vérifie pas de manière indépendante chaque exemple de correspondance décrit dans la publication d’origine. Elle n’établit pas non plus que l’ancien README enfreignait une clause précise d’une licence.

Ce qu’elle établit, c’est un lien de provenance. Artemis n’est plus présenté aujourd’hui comme une base de code développée entièrement sans code source de Minitap.

Ce changement réduit la confusion immédiate pour les nouveaux utilisateurs. Il offre aussi aux mainteneurs un point de départ pour comparer les deux systèmes et suivre les futures corrections en amont.

Apache 2.0 autorise la réutilisation, mais des conditions s’appliquent toujours

La question juridique est plus étroite que le différend éthique, car Apache 2.0 permet une réutilisation étendue sans exiger toutes les formes de reconnaissance demandées.

Les deux projets publient du code sous Apache License 2.0. Cette licence permet aux utilisateurs de reproduire, modifier, distribuer, sous-licencier et utiliser commercialement les œuvres couvertes.

Ces autorisations rendent possible la collaboration open source entre concurrents. Minitap ne peut raisonnablement affirmer que la publication de mobile-use empêchait Google de s’en inspirer.

Minitap ne formule pas cet argument. Sa publication indique que l’équipe attendait la reconnaissance du projet et de ses contributeurs.

Les conditions d’Apache 2.0 imposent plusieurs exigences lorsqu’une partie distribue l’œuvre ou une œuvre dérivée. Les destinataires doivent recevoir une copie de la licence.

Les fichiers modifiés doivent comporter des avis visibles indiquant que des changements ont été apportés. Les distributions du code source doivent conserver les avis pertinents de droit d’auteur, de brevet, de marque et d’attribution provenant de la source d’origine.

Si la distribution d’origine inclut un fichier NOTICE, les avis qui en relèvent doivent rester lisibles à un emplacement approprié. La licence permet également aux auteurs en aval d’ajouter leurs propres avis.

Ces règles ne se traduisent pas par une exigence universelle imposant une phrase spécifique dans un README. La question de savoir si l’ancien dépôt Artemis enfreignait la licence dépend des avis exacts en amont, des fichiers copiés, des modifications et de la distribution.

Par exemple, une liste d’auteurs dans les métadonnées d’un paquet peut constituer un élément pertinent de preuve de provenance. Son statut juridique dépend du fait qu’elle soit ou non considérée comme un avis que la licence impose à une distribution dérivée du code source de conserver.

De même, supprimer un nom n’est pas automatiquement illégal dans tous les contextes. Les mainteneurs modifient parfois les métadonnées de paquet parce que leur champ « authors » décrit la propriété actuelle du paquet plutôt que l’ensemble des contributeurs en amont.

Les faits environnants déterminent si cette explication est cohérente. Minitap souligne que la liste d’auteurs était apparemment le seul changement important dans la révision qu’il a comparée.

Les indications d’Apache expliquent que les avis d’attribution placés dans un fichier NOTICE en amont bénéficient d’un traitement spécifique dans les distributions en aval. Le dépôt visible de mobile-use ne présente pas ostensiblement de fichier NOTICE au niveau racine dans sa liste actuelle.

Cette absence ne réglerait pas le différend. Des avis pertinents peuvent aussi figurer dans des fichiers source ou d’autres éléments couverts, et la divulgation des modifications apportées aux fichiers reste une exigence distincte.

La différence entre le respect des licences et les normes de la communauté est cruciale. Une conduite peut satisfaire au texte juridique minimal tout en paraissant trompeuse ou irrespectueuse envers les mainteneurs.

À l’inverse, l’absence de remerciement au niveau du projet ne prouve pas à elle seule une violation de licence. Les conclusions juridiques nécessitent un examen qualifié des versions exactes concernées.

Les éléments disponibles permettent de décrire la situation comme une controverse sur l’attribution. Ils ne permettent pas d’affirmer comme un fait établi que Google a commis une violation de droit d’auteur ou volé du code.

Le terme « volé » est particulièrement imprécis lorsque le projet en amont a accordé de larges droits de réutilisation. La véritable allégation est que Google a utilisé ces droits sans préserver un crédit et une provenance adéquats.

Cette allégation reste sérieuse. Les licences permissives réduisent les restrictions, mais elles n’effacent pas la paternité ni ne privent l’ingénierie originale de propriétaire.

Les développeurs adoptant Artemis devraient conserver la licence actuelle du projet et la reconnaissance de Minitap. Ils devraient également examiner les éventuels avis intégrés avant de redistribuer des versions modifiées.

Les organisations peuvent éviter des différends similaires en traitant les prompts et les exemples comme des actifs porteurs de provenance. Les prompts d’agents contiennent de plus en plus de procédures détaillées qui façonnent le comportement d’un système aussi directement que le code conventionnel.

Un audit de publication devrait donc comparer davantage que les manifestes de dépendances. Il devrait examiner la configuration, les jeux de tests, les modèles de prompts, les exemples de documentation, les scripts de benchmark et les métadonnées de paquet.

Les équipes juridiques ne devraient pas assumer seules cette charge. Les ingénieurs les plus proches de l’implémentation savent souvent quels composants proviennent d’expériences, de prototypes internes ou de dépôts externes.

Le meilleur processus consigne l’origine lorsque le code entre dans le projet. La reconstituer avant publication est plus difficile, et la reconstituer après une accusation publique l’est davantage encore.

Les affirmations de benchmark ajoutent une source distincte de tensions

Les preuves relatives à l’attribution méritent d’être évaluées en elles-mêmes, car les désaccords sur les benchmarks ne prouvent pas la copie et n’excusent pas non plus l’absence de provenance.

Artemis affirme dépasser 99 % de réussite des tâches sur AndroidWorld. Le projet de benchmark évalue les agents sur plus de 100 tâches Android impliquant plusieurs applications.

AndroidWorld fournit un environnement reproductible pour tester si des agents peuvent réaliser des opérations réalistes sur un appareil. Les tâches peuvent inclure la modification de paramètres, la gestion du contenu d’applications et la navigation dans des interfaces à plusieurs étapes.

Un score de benchmark peut attirer des utilisateurs et établir une crédibilité technique. Il peut aussi amplifier un différend sur l’attribution lorsque deux systèmes liés rapportent des résultats très concurrents.

Minitap indique que le classement public affichait auparavant 91,4 % pour mobile-use et 99,1 % pour Artemis. Il indique que des soumissions ultérieures pour mobile-use ont rapporté 94,8 %, puis 100 %.

Ces chiffres proviennent du récit de Minitap et doivent être considérés comme auto-déclarés, à moins que les mainteneurs du benchmark ne les valident indépendamment. Minitap reconnaît lui-même cette limite.

L’entreprise affirme avoir contacté les mainteneurs du classement afin de mettre à jour le résultat de mobile-use. Elle indique également que ces tentatives n’ont pas abouti à la mise à jour demandée avant la controverse.

Aucun élément vérifié ne relie le délai du classement à la question de l’attribution dans le dépôt. Ces sujets concernent des organisations et une technologie liées, mais leur proximité temporelle n’établit pas une coordination.

Cette séparation est essentielle. Les preuves concernant le code peuvent être comparées à travers les fichiers et l’historique, tandis que la question du benchmark porte sur les versions d’évaluation, le calendrier des soumissions, les configurations des tâches et les procédures de revue.

Des scores différents peuvent résulter de causes légitimes. Un agent peut utiliser un autre modèle, des prompts différents, des outils mis à jour, des règles de nouvelle tentative modifiées ou un environnement de benchmark plus récent.

Un pourcentage annoncé révèle également peu de chose sans méthodologie. Les lecteurs ont besoin du commit testé, de la configuration du modèle, du sous-ensemble de tâches, du nombre d’essais, de la politique d’échec et de la date d’évaluation.

Artemis résume actuellement son résultat comme étant supérieur à 99 %. Son README ne fournit pas tous les détails nécessaires pour reproduire indépendamment ce chiffre à partir de cette seule affirmation phare.

Mobile-use avance ses propres solides revendications de performance. Son dépôt open source affirme être devenu le premier framework agentique à achever 100 % d’AndroidWorld.

Aucune de ces déclarations ne doit remplacer des résultats examinés indépendamment. Cette prudence s’applique autant à Google qu’à Minitap.

La transparence des benchmarks compte davantage lorsque les projets partagent des composants. Si un système hérite d’un code substantiel d’un autre, les évaluateurs doivent savoir quelles améliorations ont causé l’écart de résultat signalé.

Un score plus élevé peut venir de nouveaux contrôles de sécurité ou de l’ordonnancement de l’exécution. Il peut aussi refléter des prompts révisés, des modèles différents, des essais répétés ou des changements hérités de l’amont.

Sans configurations exactes, les observateurs ne peuvent pas attribuer l’écart de performance. Ils devraient éviter de transformer la position au classement en un verdict sur l’identité de celui qui a construit le meilleur système sous-jacent.

Le différend exerce néanmoins une pression sur le récit technique de Google. Artemis présente sa fiabilité comme une caractéristique déterminante ; une filiation transparente aiderait donc les utilisateurs à distinguer les fondations héritées des ajouts de Google.

Minitap fait face à une responsabilité analogue. Ses accusations de copie sont plus solides lorsqu’elles reposent sur des diffs durables, des hachages et des comparaisons reproductibles plutôt que sur des captures d’écran ou des résumés descriptifs.

La publication d’une comparaison structurée permettrait aux développeurs indépendants d’examiner chaque correspondance alléguée. Elle révélerait également les différences significatives qui devraient être attribuées à l’équipe Artemis.

Cet audit équilibré pourrait améliorer les deux projets. Les mainteneurs en amont gagneraient en visibilité sur les changements utiles, tandis que les utilisateurs d’Artemis pourraient suivre l’origine des composants importants.

Pour les acheteurs en entreprise, la leçon pratique est simple. Les scores de benchmark et l’image de marque d’une entreprise ne remplacent pas la diligence raisonnable sur les dépôts.

Les équipes devraient épingler les commits testés, conserver les éléments de licence, consigner les paramètres des modèles et reproduire les flux de travail critiques sur leurs propres appareils. Les agents mobiles interagissent avec des interfaces changeantes ; le pourcentage d’hier ne peut donc garantir la fiabilité de demain.

Ce que les développeurs devraient surveiller ensuite

Trois signaux détermineront si le différend autour du code de Google Artemis se conclut par une omission corrigée ou devient un problème de gouvernance plus profond.

Le premier signal est une réponse détaillée de Google ou des mainteneurs d’Artemis. La reconnaissance actuelle de Minitap est utile, mais une chronologie répondrait aux questions historiques centrales.

Cette réponse devrait identifier quels fichiers ou composants provenaient de mobile-use. Elle devrait également expliquer le remplacement du champ d’auteur et la réécriture de l’historique d’août décrite par Minitap.

Un compte rendu clair renforcerait l’interprétation en termes de supervision. Un silence prolongé laisserait inexpliqués les éléments les plus inhabituels relevés dans le dépôt.

Le deuxième signal serait une mise à jour durable de la provenance. Il faudrait surveiller l’apparition d’un fichier NOTICE, d’en-têtes au niveau des fichiers, la restauration de commits, un inventaire de code tiers ou une reconnaissance élargie des contributeurs individuels.

Toutes ces mesures ne sont pas légalement requises dans chaque dépôt. Toutefois, une cartographie précise des sources aiderait les utilisateurs en aval à respecter leurs propres obligations de redistribution.

Elle faciliterait également la maintenance future. Les développeurs pourraient comparer les correctifs en amont et déterminer si un défaut relève de mobile-use, d’Artemis ou des deux.

Le troisième signal serait une documentation de benchmarks reproductible. Les deux équipes peuvent apaiser les tensions en publiant les commits exacts, les configurations de tâches, les paramètres des modèles, les politiques de relance et les journaux d’évaluation.

Une réplication indépendante montrerait si les performances rapportées d’Artemis proviennent de sa nouvelle ingénierie, de fondations partagées, de choix de configuration ou d’une combinaison de ces facteurs.

Ces signaux comptent au-delà d’un seul dépôt. Le développement d’agents d’IA mêle de plus en plus code source, prompts en langage naturel, exemples, traces et harnais de benchmark.

Les analyseurs de dépendances traditionnels peuvent reconnaître les paquets importés tout en passant à côté de fichiers de prompts copiés ou de code transféré manuellement. Cette lacune rend l’examen humain de la provenance plus important.

Les entreprises devraient établir un registre d’intégration pour chaque composant externe. Ce registre devrait inclure l’URL source, le hash de commit, la licence, les avis, les modifications et le responsable de l’examen.

Elles devraient appliquer le même système aux prompts. Une longue instruction destinée à un agent peut intégrer des méthodes de planification distinctives, des règles d’utilisation des outils et des comportements de récupération, même lorsqu’elle est stockée sous forme de texte brut.

Les responsables de maintenance devraient également éviter, dans la mesure du possible, les modifications destructrices de l’historique à l’approche d’une publication publique. Si un force push est nécessaire, ils devraient en documenter la raison et préserver la provenance dans les commits de remplacement.

Aucune de ces pratiques n’empêche la concurrence. Elles permettent aux organisations de s’appuyer rapidement sur des logiciels permissifs tout en conservant une origine lisible.

Pour les développeurs qui hésitent entre Artemis et mobile-use, le différend ne désigne pas automatiquement un vainqueur technique. Chaque projet doit être évalué selon les plateformes, flux de travail, modèles et contrôles de vérification requis.

Artemis se concentre actuellement sur l’automatisation Android, les outils de développement, les diagnostics et plusieurs profils d’exécution. Mobile-use propose des voies de prise en charge plus larges pour Android et iOS, en parallèle de son framework d’agents.

Les utilisateurs devraient tester les deux sur des applications réelles plutôt que de se fier uniquement aux pourcentages publics. Ils devraient également suivre la manière dont chaque projet traite les problèmes, les correctifs en amont et les autorisations d’appareil sensibles sur le plan de la sécurité.

La reconnaissance actuelle signifie que Google a déjà modifié la présentation publique de la provenance. La question non résolue est de savoir s’il fournira l’explication plus approfondie qu’exige l’historique du dépôt.

Minitap doit continuer à rendre ses éléments de preuve vérifiables de manière indépendante. Google doit démontrer que son processus open source peut identifier et préserver les contributions d’une équipe bien plus petite.

C’est là l’épreuve durable. Ce nouveau crédit sera-t-il la fin de l’affaire, ou le début d’un bilan public complet sur la manière dont Artemis a été assemblé ?