En ce moment, je suis pas mal sollicité pour effectuer de la maintenance sur des sites que j'ai développé il y a plusieurs années. Revoir certaines choses, en mettre à jour d’autres, corriger tel problème… Ça me fait réfléchir sur mon métier.

⬇️

Sur le coup, c’est toujours un peu stressant : j’ai n’ai pas envie de replonger dans des vielles lignes de code, de voir tout ce qui ne va pas, et il ne faut surtout rien casser ! Je retombe aussi sur des solutions à certain problèmes, parfois originales — ou incompréhensibles.

« Mais pourquoi tu n’as pas pris le temps de commenter ton code, bon sang ?! Ah oui c’est vrai, tu avais déjà éclaté le budget de plusieurs jours… »

Et en même temps il y a quelques chose de gratifiant dans le fait de « prendre soin » — pour utiliser un terme à la mode — d’un vieux site : c’est comme réparer un vieil objet, ça peut être galère, mais on est souvent assez fier de l’avoir fait au final, surtout quand on y tient.

Par contre, réparer un objet qu’on n’aime pas, que l’on trouve moche ou mal conçu, c’est une autre histoire. Il faut essayer de trouver de l’intérêt dans l’acte même de la réparation et essayer de le transformer pour qu’il nous plaise, sinon c’est juste déprimant.

Et réparer un objet qu’on n’aime pas trop et qui en plus ne nous appartient pas… hmm. Est-ce qu'un site qu'on conçoit et/ou développe pour un client nous « appartient » ? C’est ambivalent : on en est responsable, mais il ne nous appartient plus vraiment.

Quand on design un poster ou un livre, une fois qu’il est imprimé, le boulot est fini ! C’est très rare de faire de la maintenance sur un vieux fichier InDesign, sauf pour une ré-édition d’un livre peut-être, je me trompe ?

J’imagine qu'on doit retrouver ça le dessin de caractères par contre : ré-ouvrir un vieux projet pour étendre une famille typographique, corriger certaines lettres, ajuster le spacing, ajouter des glyphes, des alternates, coder des fonctionnalités OpenType.

Il y a cette notion de « développement », qui est différente de celle de design. Développer des sites web, des applications, des programmes, des jeux-vidéo, des polices de caractère, ce n‘est pas la même pratique qu’en designer. Et en même temps c‘est hyper lié et interdépendant.

C’est ce côté travail « jamais fini », work-in-porgress qui m’interroge. On peut toujours faire mieux, améliorer, corriger, optimiser des choses… mais quand s’arrêter alors ? Quand c’est « parfait » ? Quand le temps est dépassé ? Quand on s'ennuie ? Quand le client nous gonfle ?

Il y a un tout un spectre dans les formes d’attachement entre la personne qui développe et le fruit de son travail, qui peut varier énormément en fonction de l’intérêt du projet, de la qualité des relations humaines, du montant du budget et du temps qu’on y consacre.

Projet perso auto-financé, projet cool mais relations humaines compliquées et mal payé, projet pénible payé correctement mais bonnes relations, projet passionnant mais bénévole, ennuyant mais très bien payé… Tous les combos sont possibles.

La question financière est également centrale : suis-je payé pour effectuer ce travail de maintenance / réparation ? Combien ? Selon quelles modalités ? Quels modèles économiques et contractuels seraient pertinents ? Des forfaits de maintenance ? Comment vous faites vous ?

Follow

Bref, je vais m’arrêter là, mais j’aimerais bien prendre plus le temps d’écrire sur ma pratique cette année. Mais pour ça, il faudrait qu’on arrête de m'appeler pour réparer mes vieux sites 😅

· · Web · 2 · 0 · 3

@timotheegoguely sur cette notion de jamais fini, c'est la raison pour laquelle je ne travaille plus qu'avec une notion de crédit (temps/argent), jamais sur une finalité 🤷

@dav Intéressant ! Et ça fonctionne bien en pratique, tout le monde s’y retrouve ?

Et concrètement, tu aurais un exemple de comment tu rédiges ça dans un contrat ?

@dav Merci beaucoup pour les liens, ça a effectivement très bien vieilli !

Je viens pour ma part de faire un devis pas plus tard qu'aujourd'hui, et ton article me donne envie d'essayer une formule plus proche de la tienne la prochaine fois, même si c'est un peu effrayant de prime abord pour les 2 parties : ça demande beaucoup de confiance, à la fois en soi et entre les personnes impliquées.

@timotheegoguely oui c'est ce qui m'intéresse dans la relation au/de travail 👍

@timotheegoguely Merci pour ces réflexions, et tu sais pourquoi les clients reviennent vers toi ? À quel moment la maintenance d'un site devient suffisament importante pour qu'ils te recontactent ?

@nolwennm La frontière entre la notion de maintenance et de refonte est parfois assez floue je trouve, mais typiquement on va m'appeler en me disant “On ne comprend pas, le site rame énormément depuis quelques jours, est-ce que tu peux nous aider ?”.

De là peut découler tout un tas de choses, en cherchant d'où vient le problème, on tombe sur d'autres problèmes qu'on ne peut pas s'empêcher de vouloir corriger et sur du “vieux” code qu'on n’écrirait plus du tout de la même façon avec du recul.

@nolwennm Après le facteur humain entre en compte également, mais ce ne sont pas les clients avec qui j’entretiens les meilleurs relations qui m'appellent le plus souvent.

Il y a je pense une forme de dépendance plus ou moins seine aussi qui s'installe, car en tant que développeur indépendant, on est souvent la seule personne à pouvoir résoudre les problèmes qu’ils rencontrent.

Sign in to participate in the conversation
mastodon.design

A Mastodon instance for and by people who make things!