L’une des bonnes surprises du calendrier de l’avent pour professionnel du web 24 ways, fût l’article d’Andy Clarke : Contract Killer. Andy Clarke dirige depuis maintenant 10 ans l’agence web Stuff and Nonsense. Dans cet article, il présente le contrat qu’il a écrit et utilisé ces dernières années. J’ai trouvé l’intiative très sympa, et j’ai donc choisi de le traduire.

Avertissement

Cet exemple de contrat est commode, mais il ne vaut pas un contrat rédigé par un professionnel du droit. Si vous comprenez que concevoir et réaliser des sites web est un métier, vous ne serez pas étonné que la rédaction d’un bon contrat doit passer par un avocat.

Ni Andy Clarke, Ni moi le traducteur, ne pourraient être tenus responsable des implications que pourraient avoir l’utilisation de ce contrat. Après tout, aucun de nous deux ne sommes des professionnels du droit. En utilisant cet exemple de contrat vous reconnaissez avoir lu cet avertissement.

L’avertissement n’est pas là pour vous effrayez. Il est là pour m’assurer que vous réalisez bien ce que cela implique. Il est à mon avis préférable d’utiliser un contrat qui peut être imparfait mais cependant vous protège sur certains points, que de ne rien utiliser du tout. Néanmoins, dès que vous en avez la possibilité, faîtes appel à un avocat pour qu’il vous rédige un contrat béton.

L’exemple de contrat

Entre nous [nom de l'entreprise]
et vous [nom du client]

Résumé

Nous ferons toujours de notre mieux pour remplir vos besoins et atteindre vos objectifs, mais parfois il est préférable de poser certaines choses par écrit afin que nous sachions quoi est quoi, qui doit faire quoi, et ce qu’il peut arriver si cela ne se passe pas comme prévu. Dans ce contrat, vous ne trouverez pas de termes légaux compliqués ou de long passage de texte illisible. Nous avons aucune volonté de vous piéger en signant quelque chose que vous seriez ensuite amener à regretter. Nous voulons ce qu’il y a de mieux pour la sécurité des deux parties, maintenant et dans le futur.

En bref

Vous ([nom du client]) faîtes appel à notre entreprise ([nom de l'entreprise]) domicilié à ([adresse]), pour [concevoir le design et développer un site web] pour la somme estimée à un total de [total] telle que définie dans nos précédentes correspondances. C’est bien entendu un peu plus compliqué, mais nous allons y venir.

A quoi s’engagent les deux parties?

En qualité de client, vous êtes en pouvoir et en capacité d’engager dans ce contrat, votre entreprise ou votre organisation. Vous acceptez de nous fournir tout ce qui nous est nécessaire pour achever le projet, ce qui inclus les textes, les images et les autres informations tels et quand nous en avons besoin, et dans le format que nous réclamons. Vous acceptez d’examiner notre travail, de nous fournir des retours et de signer les approbations dans les temps. Les délais à respecter s’appliquent dans les deux sens, et vous serez aussi responsable de toutes les dates que nous définirons ensemble. Vous acceptez aussi de respecter le calendrier des paiements défini à la fin de ce contrat.

Nous avons l’expérience et la capacité à réaliser les services que vous attendez et nous les réaliserons professionnellement et dans les meilleurs délais. Nous nous engageons à respecter les dates de livraison définies mais nous ne pouvons être tenus responsable pour une date de lancement ou de livraison non respectée si vous avez été en retard pour nous fournir des éléments ou que vous n’avez pas approuvé ou signé notre travail dans les temps, quelle qu’en soit l’étape.

Evidemment, nous garantissons la confidentialité de toute information que vous nous communiquerez.

Passons aux choses sérieuses

Le design

Nous créerons les designs pour l’apparence et le ressenti, la mise en page et les fonctionnalités de votre site web. Ce contrat inclus un design principal plus l’opportunité pour vous de faire deux révisions. À cette étape, si vous n’êtes pas satisfais par les designs, vous nous paierez la totalité du travail qui aura été réalisé et que nous aurons produit à ce point et vous pourrez : soit clore ce contrat, soit continuer à nous commander des révisions supplémentaires au tarif journalier défini dans notre devis initial.

Gabarits de mise en page XHTML/CSS

Si ce projet inclut des gabarits en langage XHTML ou HTML et CSS, nous les développerons en utilisant un balisage valide XHTML 1.0 Strict et des styles CSS2.1 + 3. Nous testerons notre balisage et notre CSS dans les versions actuelles de tous les navigateurs principaux incluant ceux conçus par Apple, Microsoft, Mozilla et Opera. Nous testerons aussi que les pages s’afficheront visuellement ‘semblables’, bien que pas nécessairement d’une façon identique, dans Microsoft Internet Explorer 6 pour Windows puisque ce navigateur a maintenant dépassé sa période de commercialisation.

Nous ne testerons pas ces gabarits dans des navigateurs vieux ou abandonnées, par exemple Microsoft Internet Explorer 5 ou 5.5 pour Windows ou Mac, des versions antérieures de Safari par Apple, Mozilla Firefox ou Opera sauf mention contraire. Si vous avez besoin d’afficher une apparence similaire ou identique aux visiteurs de ces vieux navigateurs, nous vous facturerons au tarif journalier défini dans notre devis initial pour tout code supplémentaire nécessaire et leur test.

Contenu textuel

Nous avons peut-être écrit un best-seller mais nous ne sommes pas responsable pour la rédaction ou la saisie d’aucun des textes sauf si nous le spécifions dans le devis initial. Nous serons cependant heureux de vous aider, et en supplément du devis, nous vous facturerons au tarif de [prix] par heure pour la rédaction ou la saisie.

Photographies

Vous nous fournirez les photographies que ce soit dans un format numérique ou imprimé. Si vous choisissez d’acheter des photographies depuis une banque d’images, nous pouvons vous suggérer des vendeurs. Tout temps que nous passerons à chercher les photographies appropriées sera facturé au tarif de [prix] par heure.

Modification et révision

Nous savons d’expérience que les contrats à prix fixe vous sont rarement favorables, puisqu’ils vous limitent à la première idée concernant l’aspect visuel, ou le fonctionnement. Nous ne voulons limiter ni vos options, ni vos opportunités de changer d’avis.

Les prix estimés au début de ce document sont basés sur le nombre de jours que nous estimons nécessaire pour concrétiser tout ce que vous avez défini pour votre projet. Si vous voulez changer d’avis, ajouter quelques pages ou gabarits ou même ajouter de nouvelles fonctionnalités, ce n’est pas un problème. Vous serez facturé au tarif journalier défini dans le devis que nous vous avons communiqué. En cours de route, nous pouvons vous demander de mettre par écrit les requêtes afin que nous puissions suivre les changements.

Support Technique

Vous avez peut-être déjà un hébergement professionnel de site web, vous administrez peut-être cet hébergement en interne ; si c’est le cas, parfait. Si vous n’administrez pas votre propre hébergement de site web, nous pouvons mettre en place pour vous un compte chez un de nos fournisseurs tiers d’hébergement préférés. Nous vous facturerons une somme forfaitaire pour l’installation de votre site sur le serveur, plus tout logiciel de statistiques tel que Mint ou Google Analytics ; ensuite les mises à jour et l’administration de ce serveur, ainsi que que tout problème de support vous incomberont.

Nous ne sommes pas une entreprise d’hébergement de site web et ainsi nous n’offrons ni n’incluons le support technique pour l’hébergement de site web, e-mail ou autres services en rapport avec l’hébergement de site web. Si vous avez besoin d’aide pour n’importe quoi en dehors du design et du développement de votre site, nous serons heureux de vous aider et nous vous facturerons au tarif de [prix] par heure.

Partie légale

Nous ne pouvons garantir que les fonctions contenues dans un gabarit de page web ou dans un site complet seront sans erreur et ainsi nous ne pouvons être tenu responsable envers vous ou tout autre tiers pour les préjudices, incluant la perte de profits, perte d’enregistrements ou autre dépenses accidentelles, dommages-intérêts indirects ou spéciaux issus du fonctionnement ou de l’incapacité à faire fonctionner le site web et toute autre pages web, même si vous nous avez prévenu de la possibilité de ce type de dommage.

Si l’une des clauses de cet accord devait être illégale, nulle, ou pour n’importe quel raison inapplicable, alors la clause devra être jugée séparément et ne devra pas avoir de conséquence sur la validité et l’applicabilité des clauses restantes.

Pfiou.

Droits d’auteur, copyright

Vous nous garantissez que tout élément de texte, graphiques, photos, designs, marques déposées ou autres iconographies que vous nous fournissez pour l’inclusion dans le site web, est votre propriété, ou que vous avez l’autorisation de les utiliser.

Lorsque nous recevons votre paiement final, le copyright est automatiquement appliqué de la façon suivante :

Vous possédez les graphiques et les autres éléments visuels que nous créons pour vous pour ce projet. Nous vous donnerons une copie de tous les fichiers et vous devrez les conserver en toute sécurité car nous ne sommes pas tenu de les garder ou de fournir les fichiers sources que nous avons utilisés lors de leur élaboration.

Vous possédez aussi le contenu textuel, les photographies et les autres données que vous aurez fournis, sauf si quelqu’un les possède. Nous possédons le balisage XHTML, CSS et autre code et nous vous donnons la licence d’usage limité à ce projet.

Nous aimons montrer notre travail et partager ce que nous avons appris avec d’autres personnes, aussi nous nous réservons le droit de montrer et de faire des liens vers le projet fini en tant qu’élément de notre portfolio et d’écrire à propos du projet sur des sites web, dans des articles de magazines et dans des livres sur le design web.

Paiements

Nous sommes sûr que vous comprenez combien il est important pour une petite entreprise comme la notre de recevoir rapidement les paiements des factures que nous vous adressons. Et comme nous sommes aussi sûr que vous souhaiterez rester amis, vous acceptez de respecter strictement le calendrier des paiements suivants.

[Calendrier paiement]

Mais où sont tous les textes en petits caractères?

Tout comme un ticket de stationnement, vous ne pouvez transférer ce contrat à quiconque sans notre permission. Ce contrat reste en place et doit être renouvelé. Si pour quelques raisons, une clause de ce contrat devenait non valide ou inapplicable, les clauses restantes demeurent en place.

Bien que le langage soit simple, les intentions sont sérieuses et ce contrat est un document légal sous la juridiction exclusive des tribunaux [français]. Oh et n’oubliez pas ces hommes avec les gros chiens.

La ligne pointillée

Signé par et au nom de [nom de l'entreprise]
Signé par et au nom de [nom du client]
Date [date]

Tout le monde doit signer au dessus et garder une copie pour ses propres archives.

Télécharger la traduction française de l’exemple de contrat (fichier texte de 11ko)

Si vous apercevez des fautes de français, ou que vous pensez que certains passages pourraient être formulés autrement (sans que cela ne modifie pour autant le texte original), laissez un commentaire.

Cet exemple de contrat est distribué sous Licence Creative Commons Attribution Share Alike, profitez en pour l’adapter à vos besoins. Andy a un style assez particulier pour écrire les contrats. Pas sûr que cela plaise à tout le monde. Et puis certains points ne doivent pas vous correspondre : tout le monde n’a pas écrit un best-seller (voir la section Contenu textuel) ou ne travaille dans les mêmes conditions.

J’espère en tout cas que cela pourra aider certains d’entre vous.

Si vous vous souciez de la qualité de vos pages HTML, vous êtes sûrement un habitué du validateur HTML ou CSS du W3C. Il s’agit sans nulle doute des pages les plus consultées du W3C. Ces outils ont besoins de serveurs, de bande passante et de temps de développement pour assurer leur pertinence.

Vous pouvez donner aux validateurs un petit coups de pouce en faisant un don, en devenant sponsor ou en vous impliquant dans leur développement. (les applications du W3C sont en Open Source)

Je profite de l’occasion pour rappeler aux utilisateurs de Mac OS X, qu’il existe une application vous permettant de tester vos pages localement selon le validateur HTML du W3C : Validator S.A.C.. Très simple à mettre en place (c’est une application comme les autres), on peut glisser les fichiers sur l’icône pour valider, et il est possible de la faire fonctionner en tant que service web. A garder précieusement sur son disque dur.

L’association Paris Web aura réussi à faire venir une belle palette d’orateurs. On notera en particulier la présence d’au moins une personne représentant chacun des navigateurs principaux (IE, Firefox, Opera et Webkit). Dont Chris Wilson qui est aussi co-chair du groupe de travail W3C sur HTML5 et Daniel Glazman co-chair du groupe de travail W3C sur les CSS.

Cela nous a offert une belle table ronde à la fin de la journée de vendredi.

Les présentations et les ateliers étaient dans l’ensemble vraiment intéressants. Le clou du spectable (en dehors de la présentation de Christian Heilmann qui sait vraiment assurer un show) fut la présentation de Stéphane Deschamps et Aurélien Levy sur l’accessibilité. Simple, avec des mises en situation, elle a permis de donner des indices sur ce qu’est le quotidien de nombreuses personnes et ce qu’il est possible de faire pour leur simplifier la vie.

Les moyens étaient aussi au rendez-vous. Comme l’année précédente, il a été possible de bénéficier de l’IBM Forum Paris. Et les ateliers ont eu lieu à l’EFREI, école plus spacieuse par rapport à celle de l’année dernière.

La cerise sur la gâteau qui méritent vraiment d’être signalée, était la présence lors de la première journée de traducteurs en langue des signes française.

Quand vous ajoutez à tout cela, les rencontres et les discussions intéressantes qui ont lieu en ce genre d’occasion. On réalise qu’il s’agit de l’un des meilleurs évènements du milieu.

Vous trouverez le reste de mes photos dans mon album Flickr de l’événement. Il y a aussi un groupe Flickr qui rassemble toutes les photos prises.

Les vidéos des présentations seront rendues disponibles dans quelques temps. Rappel, il est toujours possible de voir celles de 2007. Quand aux présentations, elles arrivent petit à petit sur Slideshare. Vous les trouverez en jonglant entre les tags pw2008 et parisweb2008.

Il est maintenant temps de retourner au travail, inspiré par ces 3 journées riches en information. Merci beaucoup aux organisateurs et aux orateurs. On se donne rendez-vous pour Paris Web 2009.

J’étais présent les années précédentes, et je reviendrais du Japon pour assister à cette 3e édition!

Le programme des journées de jeudi et vendredi s’annonce vraiment bien. Et le prix n’a quasiment pas bougé : 120€ pour 2 jours de conférences « techniques ». Un accès pour les conférences « décideurs » est disponible à 150€, un bon moyen de sensibiliser les managers. Compte tenu de la qualité des éditions précédentes, vous aurez beaucoup de mal à trouver dans le monde un événement aussi bien à un prix aussi attractif.

Quand au samedi, l’accès aux ateliers est à un prix ridicule : 12€. C’est idéal pour les étudiants. Si vos professeurs vous enseignent à créer des sites web comme il y a 10 ans, venez à la journée de samedi pour apprendre directement les bonnes techniques depuis des professionnels reconnus. Les sujets sont variés et concrets.

Dépêchez vous de vous inscrire si ce n’est déjà fait, pour profiter du prix réduit. L’inscription pour les ateliers devrait bientôt être annoncée.

Direction le site de France 2 afin de voir le journal télévisé, il ne m’offrira pas forcément la meilleure couverture mais il me donnera l’idée générale en m’épargnant la lecture de plusieurs articles. Je vais très rarement sur le site de France 2, peut-être une fois par an. Je ne connais donc pas ce site web. Je ne m’attendais pas en tout cas à tomber sur ça :

J’ai mis du temps pour repérer le logo de France 2 afin de me confirmer que j’étais bien arriver sur le bon site web. 50% de l’espace visible dans mon navigateur est occupé par la publicité. Incroyable! Je suis sur le site de Pampers Village ou celui de France 2? On peut ne pas aimer le design de France2.fr mais en tout cas on ne peut nier qu’il cherche à être propre et sérieux. Rien à voir avec la publicité bien moche de Pampers. Il n’y avait personne pour assurer une certaine cohérence entre les deux? Ce qui est sûr, c’est que cela saute aux yeux…

Daniel Glazman faisait l’echo du même problème il y a quelques jours sur le site de Libération. Encore une fois le contenu du site web est relégué au deuxième plan.

Je n’ai rien en particulier contre la publicité en ligne. Je n’utilise d’ailleurs pas de bloqueur de pubs dans mon navigateur. Je connais aussi les contraintes avec lesquelles il faut jouer pour s’assurer que sa publicité sera vue. Cependant il y a des limites à ne pas dépasser.

Est ce que France 2 compte se rattraper sur la publicité en ligne puisqu’ils vont devoir supprimer celle sur l’antenne?

Le premier test Acid est apparu en 1998, il s’agit d’un test basé sur la spécification CSS1. Son créateur Todd Fahrner avait pour soucis d’offrir un élément de référence sur le box model pour les développeurs de navigateur. Ce test de qualité a fini par rejoindre en 1999 la suite de test de CSS1.

Il aura fallu attendre 2005 pour voir l’apparition du test Acid2. Cette fois-ci le test développé principalement par Ian Hickson, teste de nombreuses propriétés CSS 2.1, mais aussi le support des PNGs transparents, de l’élément objet ou encore comment le navigateur se comporte face à des erreurs dans la feuille de style. Le test ne se concentre plus sur un domaine précis, mais regroupe différents points mal supportés par les navigateurs présents alors sur le marché et que la communauté aimerait vite voir corrigés. Ce fut indéniablement un bon moyen de motiver certaines équipes de développement, bien que l’on commençait déjà à se séparer de l’esprit de base.

Le test Acid3 est encore tout chaud. Il est sortie du four le 3 mars 2008. Encore plus ambitieux que son prédécesseur, le test Acid3 effectue 100 tests sur la page. Il se concentre principalement sur le DOM, mais comportent aussi des tests sur les sélecteurs de CSS3, sur SVG ou encore SMIL. Le soucis principal de ce nouveau test est de motiver les navigateurs à repousser leur limite. Ian Hickson aura mis près d’un an pour développer ce test Acid et il aura du faire appel à la communauté pour concevoir les derniers tests (afin d’avoir un beau score final de 100).

Malheureusement les derniers tests Acid, bien que formidable de part leur élaboration (je suis admiratif des connaissances que certaines personnes ont accumulé pour les concevoir), sont surtout un moyen de faire de la pub. Soyez le ou les premiers à passer un test Acid et le nom de votre navigateur se retrouvera sur tous les digg-like et tous les blogs et les sites ayant un lien avec le développement web. C’est ce qui a sûrement du pousser Opera a faire son annonce sans pour autant avoir une version de test de leur navigateur à offrir en téléchargement, ou pour Webkit, d’activer des aspects non finalisés de leur moteur de rendu pour valider certains tests. Il est amusant de remarquer que chez Firefox, on prend le contre-pied en précisant que non, Firefox 3 ne passera pas le test Acid3, car il y a des choses plus importantes à faire.

On en vient au final à se questionner sur les réels bénéfices apportés par le dernier test Acid. Il force les développeurs de navigateurs à implémenter des morceaux de spécification pour passer le test. Même si ces propriétés nouvellement supportées pourront se révéler utile dans de futures développement. On est bien loin de la réalité du développement web. Ne vaudrait t’il pas mieux se concentrer sur certains spécifications, voir certains aspects d’une spécification, qui répondraient à des besoins spécifiques mis à mal actuellement? Au lieu de faire un test qui s’occupe un peu de tout…

Prenons comme exemple l’adresse de mon site web. Il s’agit de mon nom de famille : Régagnon. Les noms de domaine à la base ne peuvent pas contenir un caractère avec un accent. C’est pourquoi mon nom de domaine se trouve être http://regagnon.com. Grâce aux IDN, j’ai pu aussi prendre le nom de domaine http://régagnon.com. Si vous suivez ce lien vous serez automatiquement ramener à l’adresse sans accent par la redirection que j’ai mis en place. Je permets ainsi aux personnes connaissant mon nom et n’étant pas au fait des limitations liées aux noms de domaines de quand même arriver sur mon site web ou de facilement m’envoyer un e-mail.

Cette exemple montre juste un des petits bénéfices des IDN. Les grands bénéficiaires sont les peuples n’utilisant pas l’alphabet romain. Ils n’ont ainsi plus à retranscrire les noms dans notre alphabet. Il s’agit d’un avantage pour les entreprises qui cherchent à amener leurs clients sur Internet. Ils n’ont plus à communiquer un nom de domaine qui ne correspond pas à leur nom. Et puis les IDN ont le méritent d’abaisser une des barrières d’accès au Web. Permettant aux personnes qui n’ont pas eu l’occasion d’apprendre une langue occidentale et de manier ainsi l’alphabet romain, d’accéder à des sites web avec facilité.

Pourquoi les IDN ne sont-ils pas plus visibles et utilisés? Plusieurs raisons sont en cause. Premièrement, le support des noms de domaines internationalisés par les logiciels. Internet Explorer, par exemple, ne supporte les IDN que depuis sa version 7. Sachant qu’il s’agit du navigateur le plus utilisé au monde (et surtout dans les pays asiatiques). Leurs adoptions ont été très freinées. Ils existent encore des logiciels ne supportant pas les IDN, ainsi que certains hébergeurs web.

Et puis les IDN ne sont pas encore complètement internationalisés. Un nom de domaine simple se découpe en deux parties : le second-level domain (SLD) et le top-level domain (TLD). Si je reprend mon nom de domaine comme exemple, regagnon est un SLD et .com est le TLD. Les IDN ne supportent actuellement que le second-level domain. Le TLD restant dans notre alphabet romain. Mais cette époque va bientôt être révolue! L’ICANN a lancé lundi (le 15 octobre 2007) le premier test de IDN entièrement localisé.

Il s’agit d’une étape très intéressante pour l’internationalisation du Web. C’est une avancé qui était depuis longtemps attendue par certains pays. Mais il reste encore du chemin avant la mise en place complète. La localisation des TLDs soulève quelques problèmes… Je vais vous laisser digérer ce billet. Je poursuivrais mon explication un autre jour…

Voici quelques liens Wikipedia sur le sujet :

• Noms de domaines internationalisés
• Domaine de premier niveau (TLD)
• Domaine de deuxième niveau (SLD)
• Domain Name System

Et bien non. Les japonais ont un usage plus avancé de leur téléphone portable que nous. Ils passent leur temps à s’échanger des e-mails, à parcourir le web, à jouer à des jeux ou encore à regarder la télé. Les dernières statistiques publiées par Comscore sur l’utilisation du web mobile par les japonais montrent qu’ils sont aussi nombreux à utiliser Internet depuis leur ordinateur que leur téléphone portable.

Parmi les 53,6 millions de Japonais à utiliser leur téléphone portable pour accéder à Internet. 75% s’occupent de leurs e-mails. Et plus de 50% l’utilisent pour surfer et rechercher des infos. Il m’est arrivé plus d’une fois lors d’une discussion avec un(e) japonais(e), qu’il/elle me demande d’attendre quelques minutes le temps qu’il/elle fasse une recherche rapide sur le web avec leur téléphone mobile avant de répondre à ma question.

Ces chiffres laissent présager de l’engouement probable du web mobile en France une fois que les opérateurs auront fait l’effort de concevoir des forfaits abordables et bien pensés. Je suis actuellement en train de me prendre la tête pour trouver l’opérateur et le forfait qui me permettra de gérer mes e-mails depuis mon portable, tout en ayant la possibilité de tester des pages web… Le prix annoncé de l’iPhone étant un peu trop élevé à mon goût.

Si vous souhaitez en préparation améliorer vos compétence dans le domaine du web mobile, vous pouvez vous tourner vers le dernier livre de Cameron Moll.