Dans un monde idéal, on arrêterait de réinventer la roue continuellement.

Quoi de plus banal que de recevoir une requête d’un client qui veut pouvoir mettre son site web à jour lui-même. La toile s’est tellement démocratisée depuis ses pénibles débuts qu’il est aujourd’hui courant de vouloir gérer soit même son contenu et ce, sans avoir à se lancer dans la programmation. Pour aider ces gens, il y a les CMS. Merveilleux outils qui permettent à n’importe qui (ou presque) de contrôler son petit monde virtuel. WordPress en est un exemple. Joomla, un autre. Les outils de portails en font également partis.

Vu la profusion de solutions déjà bâties, est-ce que quelqu’un pourrait m’expliquer pourquoi certaines firmes s’ingénient à développer « from scratch » un logiciel complet pour leurs clients? Ces derniers savent-ils que certaines solutions existent déjà et qu’il suffirait des les adapter à leurs besoins et ce à moindre coût.

Ha-haaaaa! J’entends d’ici certains d’entre-vous me dire que tous ces produits ne conviennent pas à tous les clients. Je suis partiellement d’accord d’abord parce que trop souvent les solutions « tablettes » ne sont même pas considérées au départ mais également parce qu’on en connaît trop mal les possibilités. Les clients qui ont réellement besoin d’une solution « custom » sont assez rares figurez-vous.

Oh! Mais, c’est tellement plus « hot » de tout refaire dès le départ. On plaide qu’il sera plus facile de contrôler le code et la maintenance car, c’est nous qui l’aurons écrit. Hum! Rien n’est moins sûr! J’ai déjà fait allusion au fait que je ne confierais pas à une équipe web la construction d’un avion si c’était dans leurs cordes tellement la qualité n’est pas nécessairement un critère dans la communauté. Vous me trouvez dure à l’égard de mes paires? Il suffit de faire de la revue de code de temps à autre et je vous garanti que quelque soit le milieu, je ne compte plus les fois où j’ai vu des variables appelées « roger », « test » et autres. J’écrirai sûrement plus longuement sur cet aspect de qualité mais ça n’est pas le point ici.

Je passerai sous silence le nom de la compagnie mais dernièrement, on m’a demandé d’auditer le code d’un site web et de l’engin d’administration (donc le CMS) maison car, on s’apprêtait à le racheter en vue de le maintenir à l’interne plutôt que de continuer à faire affaire avec la firme.

J’accepte en demandant quel « framework » ou CMS a été utilisé. Réponse : heuuuuuuu! C’est une application maison développée exclusivement pour le client.

Bon!

Et le site? Réponse : c’est du contenu principalement statique mais pour lequel il fallait avoir un accès en tout temps pour mettre à jour des images, des pdf ou des profils de produits.

Ouin! Ça commence à sentir mauvais!

Est-ce que l’application fonctionne bien actuellement? Réponse : ben, non justement, est-ce qu’il serait possible d’évaluer le temps requis pour corriger le problème x, y et z tant qu’à faire?

Pourquoi pas!

Quelle est la firme si j’ai des questions? Réponse : la firme ABC mais nous n’avons presque plus de lien avec eux. Ils n’avaient jamais fait ce genre de truc auparavent alors dès qu’on a une question, c’est compliqué.

De mieux en mieux!

Vous aimez l’application quand même de façon générale? Réponse : pas trop. C’est pas ergonomique ni intuitif. Il faut faire des tas d’étapes compliqués pour mettre un simple pdf en ligne.

Ouf! On est pas sorti du bois!

Oserais-je vous demander pourquoi vous avez choisi cette firme? Réponse : ben, c’est la direction qui a tranché… pour des motifs peu orthodoxes (je sais que vous allez grincer des dents en lisant ça et que vous allez me dire que c’est facile d’écrire ça… mais malheureusement c’est tout à fait vrai – vive le golf – et le pire, c’est que ça se produit plus souvent qu’on croit).

[…] (j’évalue le code)

Verdict : ça sera pas de la tarte! C’est en java et basé sur le framework Struts. Mal utilisé par ailleurs! Je trouve des classes en double et dans des packages différents et faisant pratiquement la même chose. Je trouve de la gestion d’erreur dans le genre – j’attape une erreur mais je n’en fais rien. Je tente de remonter la piste pour les bugs mentionnés – ouf! mais qui a bien pu coder une application si complexe pour un besoin si simple. Bon, si je corrige ceci, qu’est-ce qui va se passer… oups, ça a un impact ici… ben voyons, pourquoi… pourquoi cet imbécile de programmeur n’a écrit aucun commentaire dans ses 1357 fichiers? Je sais que les gars sont pas toujours très jasant mais quand même. Oh! Roger… la variable, bien entendu!

Je lève les yeux au ciel en écrivant mon analyse pour ce client. Que puis-je lui dire? « Vous vous êtes fait fourrer! » Non, trop direct. « Je n’investirais pas d’avantage dans cette application même pour la maintenance… ça coûterait moins cher de refaire le tout avec une plateforme comme SPIP ou Joomla. » Non, trop cynique. « Si j’étais vous, j’exigerais une documentation béton avant d’accepter de reprendre la maintenance de ce système. » Ça non plus c’est pas bon puisque ça va être l’enfer de toute façon. Mais que puis-je y faire.

Je rédige donc une analyse avec faits à l’appui et je me défoule en disant au client un peu tout ça. Réaction : c’est bon, merci… on a trouvé le programmeur qui a fait l’application et qui a quitté la firme. Il va s’en occuper.

Y a des jours où je comprends pas pourquoi les clients sont contents malgré tout!:-)