Chers clients de ProgOnline,

Notre volonté est la même que la vôtre : faire réaliser votre projet par le meilleur prestataire possible, au meilleur rapport qualité/prix. Pour ce faire, vous devez prendre en considération un certain nombre d’aspects tout au long du processus de réalisation de votre projet sur ProgOnline :

• la réputation du prestataire. Chaque prestataire est évalué à la fin de chaque projet réalisé. Cette évaluation représente “sa carte de visite”, qui lui donnera de la crédibilité (s’il est bien évalué) ou pas (s’il est mal évalué). Attention à ne pas être trop sévère avec un prestataire qui a réalisé de nombreux projets et qui a une mauvaise évaluation sur un seul projet, alors qu’il en a réalisé un grand nombre avec de bonnes évaluations (donc qui a une évaluation moyenne positive). A priori, il est par exemple préférable de faire appel à un prestataire qui a 20 évaluations et une moyenne de 8/10 qu’à celui qui a une seule évaluation de 10/10.
• les projets qu’il a réalisés sur la plateforme. C’est intéressant d’avoir une bonne évaluation, mais encore faut-il de préférence qu’il s’agisse de bonnes évaluations du prestataire sur des projets plus ou moins proches du vôtre (technologies employées, envergure du projet, timing, nature du projet, fonctionnalités).
• sa localisation géographique. Pour des projets complexes, où le donneur d’ordres n’a pas des compétences techniques pointues, et avec des budgets adaptés, il est préférable de faire appel à des prestataires géographiquement proches de chez vous. Néanmoins, l’offshore représente une solution intéressante pour bénéficier de tarifs avantageux, ou bien exploiter les compétences très pointues d’un prestataire rare, que vous ne pouvez pas trouver dans votre région géographique.
• son statut juridique :
  
  • Auto-entrepreneur. Souvent salarié à plein temps et petit entrepreneur en dehors de son travail, il représente souvent la solution la plus économique pour la réalisation de vos projets. Néanmoins, étant donné qu’il ne peut travailler sur votre projet que quelques heures par jour et/et éventuellement le week-end, sa capacité de travail est limitée. Idéal pour des projets rapides, ponctuels et avec des budgets serrés.
  • Agence web. Structure plus solide et plus pérenne que l’auto-entrepreneur, l’agence web est capable de mener à bien des projets complexes, à gros budgets, et d’assurer une maintenance technique long terme des projets réalisés. Les standards de qualités sont plus élevés, ainsi que les budgets.
  • SSII. Les Sociétés de Services et d’Ingénierie Informatique facturent le plus souvent à la journée (donc au temps passé, et non au forfait). Vous disposez d’un consultant, que vous managez le nombre de jours que vous estimez nécessaire pour la réalisation de votre projet. Si la mission dure plus longtemps, alors vous devez revoir votre budget à la hausse pour l’adapter au nombre de jours supplémentaire effectué.
  • Freelance qualifié. La différence qu’on note entre l’auto-entrepreneur et le freelance qualifié (EURL), est que le freelance qualifié travaille à plein temps pour ses clients, il a donc un devoir de rentabilité, pour pouvoir en vivre. Meilleur rapport qualité/prix pour un projet d’envergure, s’il possède toutes les compétences nécessaires pour le réaliser. Cet aspect est de taille, car pour la réalisation d’un “gros” site internet par exemple, les compétences nécessaires sont souvent multiples : design, Flash, PHP, base de données, référencement, etc…
• le “feeling” avec le prestataire. Cet aspect n’est pas à négliger, un projet informatique suppose une communication omni-présente entre le donneur d’ordre (vous) et le prestataire. Des problèmes de communication, de points de vue peuvent rapidement se mettre en travers d’un avancement optimal de votre projet.

·         Vous souhaitez faire du VOD en multicast, c’est-à-dire que tous les utilisateurs regarderont en même temps la vidéo (exemple la télévision) ou alors faire de l’unicast qui correspond à un téléchargement des différentes vidéos.

·         Le choix du serveur sera différent en fonction du choix de diffusion. Vous aurez besoin d’un serveur plus gros si vous souhaitez diffusez en streaming contrairement au téléchargement.

·         Vous possédez actuellement un site ou vous souhaitez un site clef en main

·         Si vous possédez un site, précisez quelques informations sans spécialement rentrer dans les détails précis du projet : Identification par login déjà existante, CMS utilisé s’il y en a, quel type de base de données, qu’elle technologie est utilisée, si vous souhaitez garder le même design.

·         Voici les différents points à définir pour un site clef en main

o    Quelle technologie utiliser ? (Sachez qu’un site flash VOD clef en main revient plus cher qu’un site en PHP)

o    Possédez-vous déjà une charte graphique ? (design d’un site)

o    Combien de niveaux d’administration vous souhaitez ? (pour exemple un compte administrateur qui charge les différentes vidéos et un compte utilisateur qui va lire les vidéos)

o    Inclure un système de paiement en ligne

o    Quel type de téléchargement souhaitez-vous : streaming ou téléchargement

·         Préciser comment la bibliothèque de multimédia doit se présenter :

o    Si le client dispose d’un extrait video 

o    S’il y a une recherche par auteur ou par événement 

o    Si les vidéos doivent être présentées en galerie

Tous ses éléments permettront d’avoir des prestataires plus spécifiques dans le domaine et de gagner du temps lors du départ du projet. Avoir un cahier des charges plus précis permet souvent d’avoir des offres plus concrètes.

Cet article s’adresse surtout aux membres prestataires de Progonline.

Prestataires, vous êtes nombreux à critiquer le faible taux de concrétisation des projets. Tout d’abord, il est important de discuter sur des chifres réels. Ce taux de concrétisation a toujours été constant chez Progonline, autour de 1/3, ce qui est plutôt positif : 1 projet publié sur 3 est payé par le donneur d’ordres. De plus, les améliorations dans l’ergonomie de Progonline - coté client - laissent présager une augmentation de ce taux dans les mois à venir.

Par contre, de plus en plus de clients annulent les projets parce que les offres sont superficielles, copiées-collées, sans rien à voir avec les projets, non-pertinentes. Il n’est pas rare d’observer certains prestataires faire la même offre copiée-collée sur tous les projets, ce qui n’a que des effets néfastes : le prestataire fautif n’a AUCUNE CHANCE de gagner des appels d’offres, et se décourage. Le client est déçu, et annule le projet. Pour finir, la plateforme Progonline est discréditée, parce qu’elle hebèrge des prestataires peu professionnels.

Alors, si vous voulez réellement vous donner les moyens de gagner des projets sur Progonline, un conseil : lisez bien les projets, et faites des offres adaptées aux projets pour lesquels vous postulez. Faites sentir au client que vous avez compris son projet, et que vous êtes un professionnel !

Afin de partager avec toute la communauté Progonline notre savoir faire accumulé depuis la création de notre plateforme Internet, nous mettons en libre service notre méthodologie de travail à distance.

Ce wiki est consacré au travail à distance dans le cadre du développement informatique. L’expérience montre que le travail avec une équipe multilocalisée (ex. un développeur à Madagascar, un en France, et un en Roumanie, travaillant sur des tâches précises pour le même projet) est très économique, mais très difficile à organiser pour être efficace. Cet espace représente la capitalisation de notre experience de plus de 3 ans dans ce domaine, consultable gratuitement. Vous retrouverez probablement vos problèmes et certaines solutions que nous avons expérimenté. N’hésitez pas à le compléter avec vos remarques !

http://wiki.progonline.com

J’observe avec la plus grande attention et depuis longtemps les tarifs proposés par les divers prestataires sur les projets publiés sur Progonline. Un statistique rapide montre que dans approximativement 50% des cas, ces tarifs ne sont pas pertinenents, soit parce qu’ils sont trop bas, soit parce qu’ils sont trop élevés. Prestataires, voici quelques idées qui devraient vous guider vers une meilleure évaluation de votre offre. Cet article est également valable pour les clients, qui pourront mieux piloter leur processus de séléction d’un prestataire.

Prestataires, comment fixer le tarif pour un projet ?

Progonline est une plateforme qui facilite la réalisation de projets au forfait. Pour chaque projet, ce qui compte est le résultat final livré à la date finale, et non le nombre d’heures que le prestataire a passé pour le faire réaliser. Cela ne veut cependant pas dire que le prix des projets “sort du chapeau”. Cela ne veut pas dire non plus qu’il suffit de reproduire le tarif des autres prestataires pour faire une offre gagnante.

Voici UNE possibilité, pour fixer vos tarifs : posez des questions au client jusqu’à ce que le travail à réaliser est suffisamment précis et détaillé. Grâce à votre expérience, établissez le nombre d’heures approximatif que vous allez mettre pour réaliser le projet. Multipliez ce nombre par votre taux horaire, et vous arrivez au projet en cours. C’est la modalité la plus fiable. Les prestataires qui ont de l’expérience devraient uniquement travailler comme cela : avoir un tarif horaire élevé, mais travailler efficacement, ce qui fait un tarif global intéressant pour le client.

Voici UNE autre possibilité pour fixer vos tarifs (si vous avez moins d’expérience, et pour des prestations standard) : renseignez-vous sur des acteurs économiques fiables et connus qui font le même genre de prestation, et voyez le tarif. Par exemple, allez voir le prix d’une charte graphique sur templatemonster.com, et vous verrez le prix approximatif d’une telle prestation. Allez sur wilogo.com, et vous verrez les tarifs pour un logo. etc…Prenez leur tarif comme base, et augmentez-le ou diminuez-le en fonction des demandes du client/votre réputation sur Progonline/votre expérience, etc… Pour avoir de telles références de prix, prenez des exemples d’acteurs économiques solides, qui savent ce qu’ils font et qui gagnent de l’argent sur leurs prestations, et non des prestataires qui, comme vous, n’ont pas d’idée des prix à proposer.

Et le positionnement des prestataires français et offshore les uns par rapport aux autres ?

Ce paragraphe fait l’objet d’une refléxion marketing/stratégique, et non technique. Il est néanmoins essentiel de comprendre la distinction présentée, car elle explique le comportement d’un donneur d’ordres face à la sélection d’un prestataire sur Progonline.

L’idée, qui peut frapper à premier abord, est la suivante : à compétences et réputations égales, les prestataires offshore DOIVENT être moins chers que les prestataires français, d’au moins 30% - 40%.

Prestataires français : n’oubliez pas que vous pouvez appliquer un surplus tarifaire parce que vous assurez une proximité géographique et culturelle avec le client, qui lui facilitera le travail, qui lui permettra de communiquer plus vite son besoin. Ceci constitue un argument de vente important pour vous, que vous devez mettre en valeur. C’est un réel avantage au cours du déroulement du projet.

Prestataires offshore : n’oubliez pas que lorsque le client français fait appel à vous, il mettre plus de temps à vous expliquer son projet, il ne pourra probablement pas vous appeller, il devra vous faire des cahiers de charges plus précis/détaillés. Il est normal que ces difficultés soient compensées par une économie d’argent plus importante de sa part.

Dans ces conditions, et à compétences égales, inutile pour les prestataires offshore de proposer des tarifs aussi élevés que ceux des prestataires français. Il ne s’agit pas d’exploitation ni d’injustice, mais tout simplement de la facilité du client à travailler avec vous.

Recommandations aux clients, pour la sélection d’un prestataire

Les tarifs trop faibles, à moins que le prestataire puisse faire preuve de références solides dans le domaine, sont à écarter, pour éviter de vous retrouver avec des prestataires peu professionnels.

A tarifs, réputation et compétences égales, préférez le prestataire français, si possible près de votre lieu de résidence.

Pour résumer, voici les recommandations :

• prestataires offshore et français, faites attention à vos tarifs, et ne proposez pas des tarifs “juste parce que les autres l’ont fait”
• prestataires offshore, soyez 30% moins chers que vos homologues français
• clients, ayez conscience qu’à compétences égales, un prestataire français communiquera avec vous plus facilement qu’un prestataire offshore (même parfaitement francophone - marocain, malgache, tunisien, etc…).

Le problème

Suite à de nombreux incidents de fin de projet, sur Progonline, nous avons pu sélectionner un certain nombre de points qu’il est important d’établir dès le début pour votre projet web. Cela vaut pour le client, mais également pour le prestataire. A la fin du projet, quand ces problèmes apparaissent, c’est trop tard, et le projet prend du retard. Prestataire et client entrent souvent en conflit pour cette raison.

La solution

• Définissez pour quels navigateurs et quelles versions le site web doit-il être compatible. Les clients ont le reflexe de demander ou de sous-entendre “compatibilité toutes versions, tous navigateurs (MAC, PC, IE toutes versions, FF toutes versions, Conqueror, Mozilla, etc.)”. Bien évidemment, ce n’est pas possible. Si on peut obtenir une compatibilité pour 95% des utilisateurs (il suffit de prendre les 2 dernières versions de Internet Explorer et Firefox), aller au delà est très difficile et onéreux. Sauf cas spécifiques, l’intérêt de tout le monde est de s’arrêter à ce niveau. Précisez explicitement dans votre cahier de charges les navigateurs pour lesquels il faut assurer la compatibilité, cela vous servira à la fin.
• Définissez la/les résolutions pour lesquelles le site web doit être compatible/optimisé. Même remarque que précédemment, peu de sites offrent une compatibilité toutes résolutions. Ils ont de surcroît un graphisme minimaliste et un template particulier (tout est concentré en haut à gauche). Mentionnez clairement les résolutions pour la réalisation du projet web.
  
• Faites attention aux problèmes liés à la différence d’environnement entre le serveur de test/développement et le serveur de production. Très souvent, le prestataire développe le projet sur son propre serveur, sur lequel il a un certain environnement, avec certaines versions, avec des droits le plus souvent absolus. Le site fonctionne parfaitement chez lui, mais lors du déploiement sur le serveur du client, le prestataire rencontre de sérieux problèmes :
  • la version PHP et MySQL n’est pas la même que chez lui;
  • il n’a pas accès aux crontab;
  • il n’a pas accès root à la machine;
  • il ne peut modifier le fichier php.ini;
  • il n’y a pas d’accès https;
  • etc…

Dans ce genre de cas, le mieux est de s’y préparer à l’avance, soit en développant directement sur le serveur du client, soit en synchronisant systématiquement, soit en lui spécifiant clairement qu’il devra acheter un serveur avec des droits absolus pour le déploiement de son site sur l’environnement de production. Sinon, il devra vous indiquer ce qu’il va acheter, et vous devrez vous y adapter.
Recommandation

Dans le cahier de charges, introduisez une clause : Limites du projet. Dedans, mettez toutes les limitations “sensibles”, telles que les 3 points évoqués plus haut. Pour prévenir dans une certaine mesure les sous-entendus, introduises aussi la limite suivante :

“la réalisation de ce projet ne comprend que les modules/fonctionnalités explicitement mentionnées dans ce cahier de charges. Tout module supplémentaire fera l’objet d’un cahier de charges et d’un budget supplémentaires”.

Dans le cas d’un arbitrage, cette mention n’aura de valeur que dans le cadre de fonctionnalités supplémentaires majeures, hors des us et coutumes de la typologie de projet que vous réalisez. Néanmoins, elle peut faire refléchir le client plus attentivement avant de valider le cahier de charges initial.

Le problème

Vous venez de tomber sur un projet intéressant sur Progonline, pile-poil dans votre domaine de compétences. Vous avez déjà réalisé un projet semblable, vous avez un peu de temps la semaine prochaine, et vous voulez le gagner. Mais manque de bol, le client n’a pas de spécifications précises, il ne les a pas rédigées (soit parce qu’il ne sait pas, ou il n’a pas le temps, ou il ne veut pas). En prestataire sérieux et professionnel que vous êtes, vous ne pouvez vous engager sur un forfait sans un cahier de charges précis.

Qu’est-ce que vous devez faire ?

La solution

Nous vous rappellons que le cahier de charges est LE document qui représente la pierre angulaire de tout le système de fonctionnement Progonline : délais de réalisation, coût, arbitrage/médiation, tout découle de ce document !

Voici une recommandation pour vous :

1. Tout d’abord, demandez expressément au client s’il dispose d’un cahier de charges, ou d’une description plus précise du projet.
   1. soit il dit OUI, et vous lui demandez de vous le communiquer
   2. soit il dit NON. Dans ce cas, attention ! Ne pas lui demander sèchement de cahier de charges, car très probablement il dira ‘OK’, et vous ne le reverrez plus jamais : pour un non professionnel informaticient, un cahier de charges est généralement quelque chose d’obscur et rébarbatif. Donc, s’il n’a pas de cahier de charges, demandez-lui s’il peut vous en fournir un OU s’il prefère que vous le fassiez pour lui (option importante)!
      
2. Si c’est vous qui rédigez son cahier de charges, faites-le en 2 temps :
   1. tout d’abord, AVANT d’avoir gagné l’appel d’offres, vous en faites un sommaire (les fonctionnalités principales). Cela vous permet de comprendre ce qu’il souhaite dans les grandes lignes, et de proposer un tarif.
   2. APRES avoir gagné le projet, discutez plus en détail sur le cahier de charges, définissez-le et rédigez-le, de commun accord avec le client. Postez-le sur le rapport du projet, et obtenez un accord formel écrit également sur le rapport du projet par le client (”OUI, je suis à 100% d’accord avec le cahier de charges proposé”)

Vous avez suivi cette recommandation ? Bravo, vous avez gagné le projet, vous avez un cahier de charges précis, c’est bon, maintenant vous pouvez commencer à travailler en toute sécurité !

Une petite remarque : en tant que prestataire, si vous pensez que cela vous fait plus de travail, que de rédiger un cahier de charges, pensez à 2 choses :

1. la rédaction du cahier de charges est une prestation comme toutes les autres, indispensable dans le processus de réalisation d’un projet. Si le client ne l’a pas fait, vous devez l’inclure de manière intrinsèque et statistique dans vos tarifs.
2. si c’est vous qui rédigez le cahier de charges, vous avez la garantie d’avoir parfaitement compris ce qu’il y a dedans, et de maîtriser le projet (normal, c’est vous qui le rédigez). Vous pourrez ainsi être très précis sur certains points qui vous paraissent sensibles, de poser les limites du projet à votre convenance.

Le problème

Très souvent, sur Progonline et ailleurs, les prestataires reçoivent des réclamations de la part des clients pour avoir fourni des applications “truffées de bugs”.

Le client a souvent l’impression que l’application n’est pas testée, et que le prestataire fournit un travail de mauvaise qualité, et/ou qu’il est de mauvaise foi.

A l’inverse, le prestataire a l’impression d’avoir bien testé l’application, et se plaint que le client n’explicite pas les problèmes qu’il rencontre : “ça marche pas”, “il y a des bugs”, “j’ai une erreur”, etc… ne permettent pas de résoudre les problèmes rencontrés.

La vérité sur les bugs

Tout projet informatique, qui dépasse le cadre élémentaire (qui est dépassé dans 99% des cas usuels) contient des bugs.

Il est vrai que :

• certains prestataires ne testent pas du tout leurs applications

Cependant :

• le développeur qui a conçu l’application s’est construit des schémas mentaux de son utilisation, et ne verra pas certains bugs. Il n’utilisera jamais l’application qu’il a conçue comme un réel “utilisateur ordinaire”.
• les applications sont très sensibles à l’environnement technique dans lequel elles roulent. Il est donc tout à fait possible que l’application tourne bien sur l’environnement de test du prestataire, mais pas sur celui du client.

La solution

Voici comment il faut gérer la problématique des bugs, autant du coté client que prestataires. Si les conseils suivants sont suivis, le nombre de bugs apparus diminuera rapidement, selon une courbe asymptotique vers 0.

Pour les prestataires :

• décomposer tout projet en fonctionnalités élémentaires, testables une à une. Prévoyez un temps important pour tester (vous ou vos collaborateurs) l’application.
• avant la livraison finale du projet, prendre toutes les fonctionnalités et les tester
• demander si possible à d’autres personnes de tester à votre place, elles détecterons plusieurs bugs, et seront plus efficace que le concepteur de l’application

Pour les clients :

• allouez un temps important au test de votre application en développement. Ne vous imaginez pas qu’un projet informatique est livré “clé en main”, sans aucun effort de votre part.
• soyez explicite dans le signalement de vos bugs. Détaillez au maximum, quitte à faire des copier-coller d’écrans (screenshot), pour illustrer votre propos.

Pour les clients et les prestataires :

• utilisez des outils de gestion de bugs. Il s’agit d’outils web qui permettent de signaler les bugs rencontrés, et de les classer selon leur gravité, priorité et état (résolu, en attente, fermé, etc…) De cette manière, plus rien ne vous échappe. Les outils web les plus connus sont Bugzilla et Mantis, mais il en existe beaucoup d’autres sur Internet (gratuits, en open source, en plus). Progonline utilise Mantis.

Le problème

Ce point de méthode donne quelques solutions autant préventives (faire en sorte que cela n’arrive pas) que curatives (gérer une telle situation de crise) au prestataire qui se trouverait face à une situation comme celle-ci : un cahier de charges a été rédigé, et lie le prestataire et le client dans le cadre de la réalisation du projet. Cependant, le client change d’avis sur ce qui doit être réalisé en cours de route, soit par un rajout de fonctionnalités soi-disant “sous-entendues” dans le cahier de charges, soit directement par l’annulation des spécifications du cahier de charges, pour les remplacer par d’autres.

La plupart du temps, ceci intervient pour plusieurs raisons :

• le client n’est pas assez associé au processus de développement, i.e. il prend vraiment connaissance de ce qui a été réalisé quand c’est malheureusement trop tard. Très souvent, l’expérience montre que le client “se réveille” au moment où le projet doit être finalisé, et qu’il doit payer le solde pour finalisation.
• le client a l’impression que sa demande est juste un “petit détail rapide”, alors qu’en réalité cela remet en cause la structure même du projet
• le client est perfectionniste et retarde potentiellement à l’infini la finalisation du projet pour se donner du temps de faire corriger au prestataires tous les petits détails de style, couleur, etc…
• mais aussi, dans un nombre restreint de cas, par … mauvaise foi.

Ce qu’il ne faut surtout pas faire dans cette situation

Le prestataire de bonne foi est fortement tenté d’obtempérer à la demande du client, et de réaliser ce qu’il souhaite. Seulement, comme c’est du travail supplémentaire, cela boulverse le développement et le timing. De surcroît, le projet tend à se perdre dans les détails, ce qui le complique au delà du raisonnable. Le projet prend du retard, sa complexité augmente, et le prestataire n’arrive plus à le gérer. Il est à ce moment-là responsable.

Ce qu’il faut faire dans cette situation

Bien évidemment, il n’y a pas une solution miracle, mais plusieurs réponses possibles, qu’il faut combiner :

• solutions préventives - faire en sorte que cela n’arrive pas :
  • dès le début, lors de la rédaction du cahier de charges, communiquer clairement au client que ce cahier de charges représente le document sur lequel vous vous êtes basé autant pour le tarif et pour l’echéancier, que pour la structure interne du développement. Il ne sera pas possible de le changer en cours de route.
  • faire valider systématiquement au client les étapes intermédiaires dans la réalisation du projet, et faire en sorte qu’il donne son accord formel (signature, email explicite), à chaque étape.
• solutions curatives - c’est arrivé, qu’est-ce que je dois faire :
  • laisser la modification à la toute fin du projet. Cela vous permettra de tenir vos délais de développement, et gagner la confiance du client, car vous avez tenu votre engagement. Il investira un montant supplémentaire pour les modifications plus volontiers s’il est assuré.
  • pour les détails de fin de projet qui n’en finissent plus, proposez contractuellement avec le client un délai pendant lequel il a le droit de signaler ce genre de détails. Quand ce délai est dépassé, toute modification supplémentaire sera payante.

Voilà comment il faut définir un cahier de charges pour une charte graphique de site Internet, pour avoir le maximum de chances de succès. Il faut se poser plusieurs questions et définir son besoin de la manière suivante :

• HTML pur, HTML/Flash mixte, ou Flash pur ?
• à qui s’adresse le site ?
• quelles couleurs/nuances faut-il appliquer ?
• présentez plusieurs sites internet existants, ou templates qui ressemblent plus ou moins, ou “sont dans le genre” de ce que vous cherchez (par exemple, sur templatemonster.com, il y a des dizaines de milliers de templates, certains ressemblent à ce que vous cherchez). Présentez éventuellement plusieurs templates, dont chaqun a une partie qui ressemble à ce que vous cherchez (ex, la bannière d’en haut semblable à celle du template 1, les nuances semblables à celles du template 2, et les photos dans le même style que celles du template 3, etc.).
• si vous avez une idée plus ou moins précise de ce que vous voulez, faites un croquis de ce que vous cherchez sur papier, scannez-le et fournissez-le

Avec ces éléments fournis, client et prestataire peuvent se mettre plus facilement d’accord, et éviter les malentendus liés à la subjectivité (j’aime/j’aime pas), qui interviennent souvent dans le cadre de la réalisation de travaux artistiques.