Composants Joomla sur mesure

Des extensions Joomla écrites pour votre métier

Un CMS et son catalogue d'extensions couvrent ce que font toutes les entreprises. Ils ne couvrent pas ce qui fait la vôtre : votre façon de compter, de planifier, d'inscrire ou de facturer. C'est là que nous intervenons, en écrivant ce qui manque plutôt qu'en tordant trois extensions qui n'avaient pas été prévues pour cela.

Vingt ans de métier, des extensions écrites pour des clients de Wallonie et de Bruxelles.

Ce que nous écrivons

• Des composants : une application à part entière dans votre Joomla, avec ses données, son écran d'administration et ses droits d'accès. C'est ce qu'on écrit quand le besoin a sa propre logique et ne se réduit pas à afficher du contenu.
• Des modules et des plugins : afficher la bonne chose au bon endroit, ou faire réagir le site à un événement. Ce sont les plus petites pièces, et souvent les plus utiles.
• Des templates : l'habillage écrit pour vos pages, plutôt qu'un thème du commerce dont vous n'utiliserez jamais que le quart et qu'il faudra suivre entièrement.

Dans les trois cas, nous écrivons dans les conventions de Joomla et non à côté. Vos droits d'accès, votre multilingue, vos champs personnalisés et l'historique des versions continuent de s'appliquer à ce que nous ajoutons. Une extension qui contourne le CMS s'installe très bien le premier jour, et complique tout le reste du temps, à commencer par la prochaine mise à jour de Joomla.

C'est aussi ce qui répond à la question que vous vous posez peut-être déjà : ce que nous écrivons s'installe comme n'importe quelle extension de votre Joomla, se lit dans la structure standard du CMS et n'exige aucun outil qui nous soit propre. Un autre développeur peut s'y retrouver.

Trois situations qui reviennent

La première, c'est une extension du commerce qui cesse de fonctionner. C'est arrivé sur un parc que nous suivions : la mise à jour d'un module de diaporama l'a rendu inutilisable, en administration comme à l'écran, sur tous les sites le même jour. Après avoir tout essayé, nous avons écrit le nôtre, avec les deux ou trois réglages dont ces sites avaient réellement besoin, et il a servi des années. Notre module n'était pas meilleur que l'autre, mais quand quelque chose n'allait pas, nous pouvions ouvrir le fichier.

La deuxième, c'est un logiciel métier qui doit parler avec le site. Un réseau d'agences travaillait sur un progiciel installé chez chacune, avec sa propre base de données. Nous avons écrit la passerelle : les fiches clients remontaient vers le site, les envois de courriels partaient tout seuls, et chaque collaborateur avait son compte créé sans que personne ne le saisisse deux fois. Le client n'a pas changé de logiciel métier, il a arrêté de recopier.

La troisième, c'est quand aucun produit ne couvre le besoin. Des agendas d'événements, il en existe des dizaines. Mais un agenda où un événement en contient d'autres, où les inscriptions ont un quota et une date limite d'annulation, où certaines options se facturent au groupe et d'autres à la personne, et où chaque événement peut avoir ses propres destinataires de notification, aucun assemblage d'extensions ne le tient. Il faut écrire le composant.

Nous regardons d'abord s'il faut développer

Le sur mesure coûte plus cher à l'achat et demande à être suivi ensuite. Il n'a de sens que là où le standard ne va pas, et notre premier travail est de vous dire de quel côté vous êtes.

Un client nous a demandé un jour un programme de fidélité complet pour sa boutique : des points cumulés, échangeables contre des articles. Nous lui avons répondu de ne rien faire développer. Un composant de boutique du marché savait déjà convertir des points en bons de réduction : il n'y avait que du paramétrage, c'était plus rapide et moins coûteux. C'est un conseil que nous redonnons souvent, et il nous arrive de le donner contre notre propre devis.

Vous ne savez pas de quel côté tombe votre besoin ? Dites-nous ce qu'il doit faire, le devis est gratuit.

Comment se déroule un projet

1. Nous décrivons ensemble ce que l'outil doit faire, dans vos mots et non dans les nôtres. C'est l'étape la plus utile, et c'est celle qui coûte le moins cher à refaire.
2. Nous cherchons si un produit existant le fait déjà, et nous vous le disons même quand la réponse nous coûte un développement.
3. Vous recevez un devis gratuit, qui dit aussi ce qu'il laisse de côté.
4. Nous écrivons, et vous voyez fonctionner avant la mise en service, sur une installation de test. Rien n'arrive sur votre site sans que vous l'ayez manipulé.
5. Nous installons, nous reprenons vos données existantes s'il y en a, et nous vous montrons comment vous en servir.

Ce qui fait varier le prix

Nous n'affichons pas de prix. Deux développements qui se ressemblent sur le papier peuvent demander un travail très différent, et nous préférons regarder le vôtre avant d'avancer un chiffre. Voici en tout cas ce qui fait la différence dans nos devis.

• Le nombre d'écrans que l'outil demande, côté visiteur comme côté administration.
• Le nombre de règles à respecter : un quota, une date limite, un droit d'accès, une exception. Ce sont elles qui font la longueur du travail, bien plus que la taille apparente de l'outil.
• Les données déjà là, leur volume et l'état dans lequel elles sont.
• Le raccordement à un outil que vous utilisez déjà : comptabilité, logiciel métier, annuaire, agenda.
• Le point de départ : partir d'une page blanche, ou reprendre du code écrit par quelqu'un d'autre.

Nous vous donnons ces éléments avant le devis et non après. Parlons-en.

Après la livraison

Deux choses différentes se cachent derrière « il faudrait changer ça », et nous les traitons différemment. Un défaut, c'est-à-dire un outil qui ne fait pas ce qui était convenu, se corrige. Une envie qui naît à l'usage est une évolution : elle est souvent une bonne idée, et elle se chiffre.

Quand nous corrigeons quelque chose sur une extension que nous avons écrite, vous n'avez pas à le découvrir ni à le réclamer. Si votre site est suivi, la correction est posée au passage prévu, avec le reste, et le compte rendu vous dit ce qui a changé.

Ce qui se passe quand Joomla change de version majeure

Une extension sur mesure ne traverse pas seule une montée de version majeure de Joomla. Votre logique métier, elle, ne bouge pas. Ce qui change, c'est le socle sur lequel elle s'appuie, et il faut réécrire ce qui s'y accrochait.

Nous l'avons mesuré sur une de nos propres extensions : un petit utilitaire d'une soixantaine de lignes, dont pas une seule règle métier n'a bougé, a demandé la réécriture d'environ la moitié de son code pour passer d'une génération de Joomla à la suivante. C'est peu, mais ce n'est pas rien, et cela vaut pour toutes les extensions, les nôtres comme celles du marché.

Nous en tirons trois façons de travailler.

• Écrire selon les conventions du CMS, parce qu'une extension bâtie sur la structure standard de Joomla se porte à moindres frais, là où celle qui l'a contournée est souvent à refaire.
• Suivre les fins de support, du CMS comme de PHP. Ces échéances sont connues des mois à l'avance, ce qui laisse le temps d'en parler, de chiffrer le portage et de choisir le moment.
• Traiter le portage comme un chantier à part, avec son devis. Il n'est pas compris dans le contrat de maintenance, qui exclut déjà les montées de version majeures du CMS.

Entre deux montées de version, si votre site est suivi, votre extension entre au calendrier au même titre que le reste, à une cadence adaptée à ce qu'elle fait. Sortie du calendrier, une extension n'est plus regardée, et on s'en aperçoit généralement le jour où elle pose un problème.

Et si l'extension existe déjà ?

Nous reprenons aussi du code écrit par quelqu'un d'autre. L'exercice commence toujours par la même chose : lire ce qui existe, et vous dire honnêtement si cela se remet en état ou s'il vaut mieux le réécrire. C'est le même raisonnement que pour les sites, expliqué sur la page reprise de site existant.