FR2943155A1 - Procede et systeme collaboratif de modifications d'applications numeriques en reseau - Google Patents

Abstract

L'invention vise à permettre un développement collaboratif simplifié et accéléré à partir de mécanismes interactifs, afin d'optimiser ce développement en tenant compte directement de manière constructive et dynamique des apports des utilisateurs. Le procédé collaboratif selon l'invention comporte un réseau de transmission de données entre un serveur et des terminaux utilisateurs. Un utilisateur transmet une requête auprès du serveur pour télécharger le code d'exécution binaire d'au moins une partie de l'application à exécuter. Les étapes suivantes se déroulent alors : transmission d'une requête de l'utilisateur auprès du serveur pour obtenir le code source associé à un module à modifier ; identification par le serveur de ce code source associé ; modification du code source exécutable par l'utilisateur et transmission du code source modifié au serveur ; recompilation par le serveur des modifications du code source et, si la recompilation aboutit, mise à jour des données binaires et du code source ; et substitution du module recompilé au module transmis initialement puis transmission, à partir du serveur, du module de code binaire ainsi recompilé aux utilisateurs du réseau ayant téléchargé l'application.

Description

PROCEDE ET SYSTEME COLLABORATIF DE MODIFICATIONS D'APPLICATIONS NUMERIQUES EN RESEAU

DOMAINE TECHNIQUE DE L'INVENTION [0001]L'invention se rapporte à un procédé de développement collaboratif d'applications numériques et de mise à jour ou corrections par modifications de ces applications accessibles en réseau. L'invention se rapporte également au système de mise en oeuvre de ce procédé. [0002] Le domaine de l'invention est celui de la réalisation et de l'optimisation interactive d'applications informatiques.

ETAT DE LA TECHNIQUE [0003] Pour améliorer une application collaborative, un utilisateur doit télécharger la dernière version du code source de l'application, déterminer l'éditeur de code, le compilateur approprié, les bons fichiers et librairies. La compilation du code source est exécutée en local et les modifications sont ensuite transmises aux administrateurs de l'application. Les administrateurs doivent alors fusionner les modifications et publier une nouvelle version de l'application. Les utilisateurs peuvent alors télécharger et installer la nouvelle version en local. Tout ce processus est complexe et mobilise un temps excessif. [0004] Il est par exemple connu du document de brevet américain n°US2008/0243852 une mise en oeuvre d'un système et d'un procédé permettant de modifier une page Web au format Wiki dont le contenu est compatible et portable sur tout type de navigateur internet. [0005] Lorsque l'application est téléchargée d'une partie serveur et exécutée sur une partie cliente au travers, par exemple, du navigateur Internet de l'utilisateur, ce dernier a la possibilité d'effectuer une ou plusieurs modifications sur une page Web de cette application. [0006]Ces modifications ne sont possibles que si l'utilisateur appartient à une liste d'administrateurs qui définit les droits associés aux actions qu'il peut réaliser. [0007] En activant un élément appartenant à l'interface graphique de cette page, l'utilisateur peut apporter des modifications en particulier à son contenu archivé dans les bases de données du serveur. Une fois ces modifications réalisées l'utilisateur les valide. Des données correspondant au contenu modifié sont ensuite transmises au serveur afin de mettre à jour la page Web. [0008]Ainsi, ces modifications sont immédiatement visibles sur la page Web modifiée de l'application. Néanmoins cette solution ne permet pas de faire évoluer les aspects intrinsèques de l'application. [0009] Par ailleurs, le document de brevet US2009/0030918 décrit un procédé pour le développement collaboratif d'un projet à partir d'un outil simplifiant le travail collaboratif. [0010] Cette application comprend une interface graphique comportant des éléments activables pour initier la création du projet, et la définition des droits des utilisateurs habilités à participer au développement dudit projet. [0011 ]Les données se rapportant à l'application sont transmises par une partie serveur à une partie client en vue notamment d'afficher l'interface graphique de cette application avec laquelle l'utilisateur va interagir. [0012] Lors de l'étape de création du projet, des champs d'une base de données connectée à la partie serveur sont initialisés, et des outils sont créés et paramétrés au niveau du serveur. Une fois créé, le projet est transmis aux utilisateurs définis et habilités à participer à son développement. [0013] Lorsqu'un de ces utilisateurs souhaite modifier ce projet, il se connecte à la partie serveur, exécute l'application et sélectionne la partie qu'il souhaite modifier qui s'affiche sur son terminal et active l'élément de l'interface graphique à modifier.

Un ensemble de données est ensuite transmis à la partie serveur qui archive dans une base de données l'objet des modifications, l'identité de l'utilisateur ayant réalisé cette modification et l'historique des actions réalisées sur ce projet par cet utilisateur. [0014]Le projet peut par la suite être mis à jour par les autres utilisateurs qui pourront disposer d'un ensemble d'informations sur les modifications effectuées sur le projet. [0015]Cette solution ne porte que sur l'élaboration d'un projet de développement collaboratif, avec partage des données en ligne. Aucune application n'est exécutée en ligne. Ce système laisse la charge au développeur de chercher en ligne les sources dont il souhaite profiter pour faire évoluer ledit projet.

BREF EXPOSE DE L'INVENTION [0016] L'invention vise à permettre un développement collaboratif simplifié et accéléré à partir de mécanismes interactifs, afin d'optimiser ce développement en tenant compte directement de manière constructive et dynamique des apports des utilisateurs, tant sur le développement d'une application que sur ses corrections ou mises à jour. Les apports en développement, correction ou mise à jour d'une application sont regroupés ci-après sous le terme modifications . [0017] Pour ce faire, l'invention propose d'agir directement par l'interface de l'application à travers le module de code source à modifier fournie par le serveur, les modifications de chaque utilisateur-collaborateur étant ensuite répercutées sur le code binaire des autres utilisateurs après recompilation des modifications au niveau du serveur. Ainsi chaque utilisateur est potentiellement un collaborateur apte à fournir des modifications sur lesquelles pourront réagir les autres utilisateurs. [0018] Plus précisément, l'invention a pour objet un procédé collaboratif de modifications d'applications numériques, comportant un réseau de transmission de données entre un serveur et des terminaux utilisateurs, dans lequel un utilisateur transmet une requête auprès du serveur pour télécharger le code d'exécution binaire d'au moins une partie de l'application à exécuter et dans lequel les étapes suivantes se succèdent : - transmission d'une requête de l'utilisateur auprès du serveur pour la transmission du code source associé à un module à modifier ; - identification par le serveur du code source associé a ce module et 30 transmission de ce code source à l'utilisateur aux fins de modification ; - modification du code source exécutable par l'utilisateur et transmission par l'utilisateur du code source modifié au serveur ; - recompilation par le serveur des modifications du code source et, si la recompilation aboutit, mise à jour des données binaires et du code source ; et - substitution du module recompilé au module transmis initialement puis transmission, à partir du serveur, du module de code binaire ainsi recompilé aux utilisateurs du réseau ayant téléchargé l'application.

[0019]Selon des modes de réalisation particuliers : - le serveur est apte à compiler les données source en données binaires et apte à gérer ces données pour les transmettre, les recevoir et les stocker à partir de priorités prédéfinies; - les priorités prédéfinies sont choisies parmi: le blocage de modifications en cours lorsqu'une version modifiée de l'application reçue par le serveur est validée, la transmission des modifications au fur et à mesure de leur compilation à tous les utilisateurs, et la transmission de toutes les modifications à tous les utilisateurs au fur et à mesure de leur réalisation après fusion des versions compatibles ; - un éclatement de la partie serveur dans chacun des terminaux des utilisateurs afin de permettre un fonctionnement de type peer to peer ( paire à paire en anglais) entre utilisateurs; - le client valide le bon fonctionnement des modifications avant transmission du module modifié au serveur ; - la recompilation peut être effectuée soit sur le serveur soit sur le terminal de l'utilisateur, ce dernier transmettant alors au serveur le code source et les données binaires recompilés. - le serveur évalue, dans une étape préalable à l'étape de substitution, la nécessité de prendre en compte de façon immédiate ou décalée les modifications apportées. - le module à modifier est une donnée multimédia à laquelle est associé un comportement logique par le serveur.30 [0020]L'invention se rapporte également à un système collaboratif de mise en oeuvre du procédé défini ci-dessus. Dans ce système, le serveur comporte des bases de données de fichiers binaires d'au moins une application et de code source en langage exécutable correspondant aux fichiers binaires, ainsi que des moyens de calcul pour la compilation et la gestion des données en fonction de règles d'exécution et de priorité. Une interface entre une partie serveur et une partie clients-utilisateurs regroupant l'ensemble des terminaux reliés au réseau véhicule les données entre chaque base de données du serveur et la partie client. [0021 ]Selon des modes de réalisation particuliers : - l'application comportant une interface graphique ayant des éléments, un accès au code source correspondant est réalisé par cliquage sur ces éléments ; - le serveur télécharge alors le code source qui est affiché soit dans un éditeur inclus dans l'application soit dans un éditeur externe ; - l'application comporte une interface de sélection d'implémentation, permettant de trouver et de sélectionner, pour une interface définie, une implémentation particulière par l'intermédiaire de critères de qualité ou de popularité.

BREVE DESCRIPTION DES FIGURES [0022] D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description qui suit d'exemples de réalisation non limitatifs, en référence aux figures annexées qui illustrent, respectivement: - la figure la, un diagramme de séquence de démarrage d'une application cliente et de modification par l'utilisateur; - la figure 1 b un diagramme linéaire de l'exécution et de la modification d'une application ; - les figures 2a et 2b, un schéma d'interface graphique permettant, par pointages successifs d'accéder au code source correspondant à un élément graphique à corriger; - la figure 3, un diagramme de validation des modifications opérées par l'utilisateur ; - la figure 4, un diagramme de téléchargement progressif de l'application adapté à la gestion des modifications ; - la figure 5, un diagramme de prise en compte de nouvelles versions pendant l'exécution de l'application ; - la figure 6, un diagramme de réduction des chaînes de dépendance dans les recompilations ; - la figure 7, un diagramme d'aide à la sélection d'une version parmi plusieurs versions modifiées de l'application; - la figure 8, un diagramme d'accès à des données à modifier en rapport avec un élément graphique de l'application ; et - la figure 9, une illustration d'une interface graphique de sélecteur d'implémentation.

DESCRIPTION DETAILLEE D'EXEMPLES DE REALISATION

[0023] En référence aux diagrammes des figures la et lb, un exemple de mise à disposition d'une application cliente en vue de sa modification est illustré. [0024] Dans une étape préalable de démarrage de l'application, le client A demande le téléchargement des modules de fichiers binaires de son application (étape 100) et exécute l'application à partir de l'ensemble des fichiers binaires téléchargés (étapel02). L'application cliente offre ainsi à l'utilisateur U du réseau R la possibilité de modifier l'application à partir de fichiers modifiables (étape 104) transmis par un serveur S.

[0025] L'utilisateur connecte son terminal informatique PC à un serveur distant, à travers une application dédiée. Au lancement de l'application, l'application cliente, située sur le terminal de l'utilisateur, contacte le serveur hôte qui transmet les fichiers binaires principaux d'exécution du programme et les modules dépendants, comportant les modules de la partie de l'application modifiable (étape 106). [0026] L'utilisateur peut donc librement exécuter l'application souhaitée sur son terminal. [0027]Dans le cas où une modification lui apparaît opportune, l'utilisateur sélectionne l'élément du programme à modifier en lançant l'action de modification à travers un élément d'interface Homme/Machine dédié (étape 108). Le serveur transmet alors le code source téléchargé par l'application cliente et correspondant à l'élément que l'utilisateur a décidé de modifier (étape 110). [0028] Lors de l'exécution de l'instruction de modification, le programme client envoie une requête au serveur afin d'obtenir le code source associé au module binaire à modifier (étape 112). [0029] Le serveur recherche dans sa base de donnée le code source associé et le transmet à l'utilisateur. Une fois le fichier reçu, une fenêtre d'édition s'ouvre et permet à l'utilisateur de modifier le code source (étape 114). Le code source peut être téléchargé soit dans un éditeur intégré soit dans un éditeur externe. [0030] Les figures 2a et 2b illustrent schématiquement l'accès, à partir d'une interface graphique au code source d'un élément graphique. [0031]Dans la fenêtre 10 de l'interface graphique de l'application, un bouton 12 est prévu pour modifier le code source d'un élément 14 visualisé sur la fenêtre ou d'autres fenêtres de l'application par cliquages successifs (figure 2a). [0032] Dans une réalisation alternative, le pointeur 16 de la souris est positionné sur l'objet 18 à modifier (figure 2b) : un menu contextuel 20 apparaît automatiquement, muni d'une commande 22 de modification du code source associé à l'objet. [0033]Après modification du fichier, en référence de nouveau à la figure 1, l'application cliente peut offrir à l'utilisateur la possibilité de valider les modifications opérées sur le code source (étape 116), afin de s'assurer du bon fonctionnement du nouveau code. [0034] Après validation ou directement sans validation, l'application transmet au serveur le fichier modifié (étape 118) dans un processus de recompilation des fichiers binaires correspondant aux modules modifiés, tel qu'illustré à la figure 3. [0035]Le serveur recevant le fichier modifié va procéder à la compilation du code source, cette opération pouvant être effectuée sur le serveur ou être expatriée sur un autre serveur (étape 120). [0036] La compilation peut aboutir ou pas. Dans le cas où le code ajouté n'est pas correct (erreur de syntaxe, etc.), le processus de compilation n'aboutit pas (pavé 122) et un message d'erreur est envoyé à l'application cliente : les modifications sont annulées et l'utilisateur en est informé (étape 124). [0037]Si la compilation aboutit, le serveur met à jour sa base de fichiers binaires et sa base de code source (étape 126) et l'utilisateur est informé que ses modifications ont été prises en compte (étape 128).

[0038]Avantageusement, les codes et fichiers ne sont pas uniquement retransmis à l'application cliente mais à l'ensemble des applications clientes connectées au serveur et ayant téléchargé ce module. Ainsi tous les utilisateurs bénéficient des modifications en temps réel. Éventuellement, les utilisateurs sont informés par un message de l'arrivé de nouveaux fichiers modifiant le comportement de l'application afin de bien l'identifier.

[0039] Dans un soucis d'optimisation des échanges en réseau, un exemple de réalisation avantageux met en place, en référence à la figure 4, un téléchargement progressif des modules exécutables de l'application au fur et à mesure de son exécution. [0040] Dans ce cas, l'application cliente télécharge du serveur (étape 400) des fichiers binaires découpés par exemple par classe. Le serveur établit la liste des références entre les fichiers. Cette liste est soit greffée aux fichiers soit stockée dans le serveur. Les fichiers contiennent la classe de démarrage de l'application, ainsi que les classes directement référencées par celle-ci. [0041]Le client crée ensuite une instance de la classe de démarrage et exécute l'algorithme principal (étape 402). [0042]Chaque fois qu'une nouvelle instance de classe doit être créée (étape 403), le client évalue si la classe a déjà été téléchargée (étape 404). [0043]Si la classe n'est pas présente en local, le client émet une demande au serveur afin de télécharger la classe et les dépendances nécessaires à son instanciation (405). [0044] La classe est ensuite instanciée en mémoire (406) par le client, que la classe ait été présente en local ou téléchargée à partir du serveur. L'exécution reprend ensuite son cours normal (itération 40).

[0045] Pendant l'exécution progressive de l'application, il est également avantageux de pouvoir bénéficier des nouvelles versions des classes réalisées par les autres utilisateurs, sans avoir à redémarrer l'application. Pour ce faire, les dernières versions sont prises en compte lors de la création des nouvelles instances après vérification de leur compatibilité. [0046] Le client demande alors au serveur - lors de l'instanciation d'une classe - le fichier binaire correspondant à la version la plus récente de la classe parmi celles qui sont compatibles, à moins qu'il ne possède déjà une version compatible. Le diagramme de la figure 5 illustre un exemple de détermination de la compatibilité d'une version. [0047] Dans cet exemple, si V est la version de la classe B dont l'instance est en cours, alors que le client cherche à instancier une version X de la classe C (B et C pouvant être identiques) dans l'étape 500, les classes référencées par X et les classes parentes de V (c'est-à-dire dont V hérite) sont listées pour former respectivement L1 et L2 (étape 502), L2 incluant V. L'intersection I des listes est alors déterminée (étape 504): si l'intersection I contient deux versions différentes d'une même classe, alors la version X n'est pas compatible avec la version V (étape 506). Sinon, la version X est compatible avec la version V (étape 508). [0048] Régulièrement, le client met à jour avantageusement les fichiers binaires qu'il possède, en téléchargeant à partir du serveur les dernières versions.

[0049]Afin de permettre une prise en compte efficace des modifications effectuées à l'application en cours d'exécution, il est utile de réduire le nombre de recompilations induit par ces modifications sur l'ensemble des fichiers dépendants des fichiers modifiés. [0050] Cette variante vise donc à réduire de façon automatique la longueur de chaînes de dépendances entre les classes, c'est-à-dire finalement le nombre d'éléments de la chaîne (correspondant au maximal de recompilations nécessaires lorsqu'un élément de la chaîne est modifié).

[0051]La réduction est réalisée par interposition d'une classe abstraite (ou d'une interface) reprenant tous les membres publics de la classe dépendante et générée automatiquement par instanciation dynamique de cette classe. [0052] Dans un exemple de réalisation illustré en figure 6, une classe abstraite formant une interface 60 est générée automatiquement à partir de chaque classe dépendante C2 référencée par une classe Cl. Partout dans le code les classes référençant C2 sont changées afin de pointer vers la classe abstraite 60 au lieu de pointer vers la classe concrète C2. Seuls les endroits où le constructeur est appelé (par exemple via le mot clé new ), l'instance est créée au moyen d'une analyse de l'instanciation dynamiques des objets, ce qui permet d'éliminer toutes références en dur vers la classe concrète. [0053] Si les membres publics d'une classe n'ont pas été modifiés, la dernière version de la classe peut alors être utilisée. L'utilisation de la dernière version compatible, telle que déterminée ci-dessus, est alors particulièrement efficace.

[0054]Selon une variante avantageuse, en référence à la figure 7, l'application est apte à permettre aux utilisateurs de sélectionner une version de module parmi les meilleurs modules mis en avant. [0055]A cette fin, la sélection d'un module est opérée à partir de la liste des classes qui implémentent une interface spécifiée ou qui héritent d'une classe de base spécifiée. Une interface est une définition de classe, dont le programmeur hérite pour implémenter une classe selon des conventions établies. Pour aider au choix, les éléments de la liste sont ordonnés selon au moins un critère spécifié. [0056] Dans l'exemple illustré en figure 7, l'application cliente envoie une requête (étape 701) au serveur pour obtenir l'ensemble des classes qui implémentent l'interface servant de filtre de recherche, en fonction d'un critère spécifié dans la requête. [0057] Le critère spécifié dans la requête peut être par exemple : la popularité de la classe, le nombre de fois où elle figure dans les favoris, le nombre de fois où elle a été choisie, la date de la modification, etc. [0058] Le serveur retourne la liste des classes correspondantes au critère, après avoir recherché dans sa base de code source ( 703). [0059]La liste reçue par l'application cliente est affichée (figure 9) dans l'application cliente (figure 9, 902), et l'utilisateur peut alors choisir son implémentation préférée (705). La liste est accompagnée de critères d'aide au choix (904) (popularité, note attribuée, date, etc.). [0060] Ensuite le choix de l'utilisateur est instancié par l'application, en demandant au serveur le module binaire correspondant au code choisi (707). Le serveur recherche alors dans sa base de données binaires, le module binaire associé au code sélectionné et le transmet au client qui est apte à l'instancier. [0061 ]Une instanciation automatique de la classe choisie peut être demandée par l'application. L'instance est alors passée au code de l'application sous forme d'une 20 instance de type interface de base ou type de base. [0062]Selon un exemple concret, un éditeur d'images dispose de filtres comme la luminosité, le contraste, etc. Son code source contient une interface de type IFiltre (l'interface définit simplement le type d'entrée et le type de sortie attendu des filtres). Avec le sélectionneur d'implémentations décrit ci-dessus, tout utilisateur 25 peut ajouter de nouveaux filtres en ajoutant à l'application des classes qui implémentent IFiltre. Le sélectionneur d'implémentations permet ainsi d'obtenir automatiquement la liste de tous les filtres. Lorsqu'un utilisateur en choisit un, ce dernier est automatiquement instancié et passé à l'application en tant qu'instance de type IFiltre, ce qui permet à l'application de l'utiliser. 30 [0063] Dans une variante de réalisation, en référence à la figure 8, des éléments graphiques de l'application cliente sont associés par le serveur à d'autres données qu'aux données du code source par un identifiant unique à partir d'un élément graphique quelconque de l'interface de l'application. Cet identifiant est alors utilisé pour accéder à des données. Ces données peuvent être par exemple des suggestions, un fil de discussion, une liste de tâches concernant l'élément graphique, la liste des utilisateurs qui sont en train d'utiliser ou de modifier l'élément graphique, etc.

[0064] Conformément au diagramme illustré en figure 8, lorsque l'utilisateur clique sur un élément graphique (ou un élément qui lui est rattaché, comme un bouton ou un menu contextuel), la série d'actions suivante est déclenchée : o sélection de l'instance correspondant à l'élément graphique de l'application (étape 801) : si l'utilisateur clique directement sur l'élément, cette détermination peut se faire via un mot clé tel que this ( ceci en anglais), sinon elle peut se faire via un lien établi par le développeur, ou en recherchant les éléments parents de l'élément cliqué ; o détermination, grâce à une fonction interne décrite ci-dessous, de l'identifiant unique de la classe qui correspond à ladite instance (étape 803) ; o utilisation de cet identifiant pour accéder aux données relatives à l'élément cliqué (étape 805) : suggestions, discussions, tâches, etc., par transmission d'une requête au serveur contenant un identifiant unique possédé par la classe instanciée. Cet identifiant peut être par exemple: le nom complet de la classe, un numéro arbitraire d'identification attribué lors de la création de la classe, etc. o le serveur retransmet ces données à l'application cliente qui les affiche (807). Ces données peuvent êtres des données multimédia (sons, images, lien hypertextes, données textuelles) de tout type transmissible par réseau.

[0065]Afin d'obtenir l'identifiant à partir de l'instance d'une classe, l'application cliente possède une fonction interne pouvant être réalisée de multiples façons, par exemple : o en obtenant via analyse dynamique des objets dite reflection le nom complet de la classe ; o en obtenant via reflection le nom du fichier binaire à partir duquel la classe s'exécute (en supposant que chaque fichier binaire contient une seule classe et que le nom du fichier binaire permet de déterminer l'identifiant de la classe) ; o en ayant préalablement ajouté à la classe (lors de sa compilation) un champ permettant d'obtenir son identifiant.

Exemples concrets d'applications : • attacher des suggestions à n'importe quel endroit de l'application ; • à partir d'une fenêtre quelconque de l'application, discuter avec les autres utilisateurs qui utilisent au même moment la même fenêtre ; • contribuer à l'aide contextuelle de tout élément graphique directement à partir de ce dernier.

Claims (12)

1. REVENDICATIONS1. Procédé collaboratif de modifications d'applications numériques, comportant un réseau de transmission de données entre un serveur et des terminaux utilisateurs, dans lequel un utilisateur transmet une requête auprès du serveur pour télécharger le code d'exécution binaire d'au moins une partie de l'application à exécuter, ce procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - transmission d'une requête de l'utilisateur auprès du serveur pour la transmission du code source associé à un module à modifier ; - identification par le serveur du code source associé a ce module et transmission de ce code source à l'utilisateur aux fins de modification ; - modification du code source exécutable par l'utilisateur et 15 transmission par l'utilisateur du code source modifié au serveur ; - recompilation par le serveur des modifications du code source et, si la recompilation aboutit, mise à jour des données binaires et du code source ; et - substitution du module recompilé au module transmis initialement puis transmission, à partir du serveur, du module de code binaire ainsi recompilé 20 aux utilisateurs du réseau ayant téléchargé l'application.
2. 2. Procédé collaboratif selon la revendication 1, dans lequel le serveur est apte à compiler les données source en données binaires et apte à gérer ces données pour les transmettre, les recevoir et les stocker à partir de 25 priorités prédéfinies.
3. 3. Procédé collaboratif selon la revendication précédente, dans lequel les priorités prédéfinies sont choisies parmi: le blocage de modifications en cours lorsqu'une version modifiée de l'application reçue par le serveur est vérifiée et validée, la transmission des modifications au fur et à mesure de leur compilation 30 à tous les utilisateurs, et la transmission de toutes les modifications à tous les utilisateurs au fur et à mesure de leur réalisation avec une fusion des modifications compatibles.
4. 4. Procédé collaboratif selon l'une quelconque des revendications précédentes, dans lequel un éclatement de la partie serveur dans chacun des terminaux des utilisateurs est effectué afin de permettre un fonctionnement de type peer to peer entre utilisateurs.
5. 5. Procédé collaboratif selon l'une quelconque des revendications précédentes, dans lequel le client valide le bon fonctionnement des modifications avant transmission du module modifié au serveur.
6. 6. Procédé collaboratif selon l'une quelconque des revendications précédentes, dans lequel la recompilation peut être effectuée soit sur le serveur soit sur le terminal de l'utilisateur, ce dernier transmettant alors au serveur le code source et les données binaires recompilés.
7. 7. Procédé collaboratif selon l'une quelconque des revendications précédentes, dans lequel le serveur évalue, dans une étape préalable à l'étape de substitution, la nécessité de prendre en compte de façon immédiate ou décalée les modifications apportées.
8. 8. Procédé collaboratif selon l'une quelconque des revendications précédentes, dans lequel le module à modifier est une donnée multimédia à laquelle est associé un comportement logique par le serveur.
9. 9. Système collaboratif de mise en oeuvre du procédé selon l'une 25 quelconque des revendications précédentes, caractérisé en ce qu'il comporte un serveur intégrant des bases de données de fichiers binaires d'au moins une application et de code source en langage exécutable correspondant aux fichiers binaires, des moyens de calcul pour la compilation et la gestion des données en fonction de règles d'exécution et de priorité, ainsi qu'une interface entre une partie 30 serveur et une partie clients-utilisateurs regroupant l'ensemble des terminaux reliés au réseau et véhiculant les données entre chaque base de données du serveur et la partie clients-utilisateurs. 10 15 20
10. 10. Système collaboratif selon la revendication précédente, dans lequel l'application comporte une interface graphique ayant des éléments, un accès au code source correspondant est réalisé par cliquage sur ces éléments.
11. 11. Système collaboratif selon la revendication précédente, dans lequel le serveur télécharge le code source qui est affiché soit dans un éditeur inclus dans l'application soit dans un éditeur externe. 10
12. 12. Système collaboratif selon la revendication précédente, dans lequel l'application cliente comporte une interface de sélection d'implémentation, permettant de trouver et de sélectionner, pour une interface définie, une implémentation particulière par l'intermédiaire de critères de qualité ou de popularité. 15