Applications métier sur mesure

Des applications métier pour ce qu'un site ne sait pas faire

Il arrive un moment où le besoin ne tient plus dans des pages. Il faut que quelque chose tourne la nuit pendant que personne ne regarde, qu'un document se fabrique tout seul et parte au bon destinataire, qu'un outil aille chercher dans un autre ce que quelqu'un recopie encore à la main aujourd'hui. Là, nous écrivons une application.

Vingt ans de métier, en Hainaut, pour des clients de toute la Wallonie et de Bruxelles.

Quatre choses qu'un site ne sait pas faire

Un site attend qu'on vienne le voir. Une application métier, elle, travaille même quand personne ne la regarde. Quatre demandes reviennent plus souvent que les autres. Nous les avons toutes écrites au moins une fois.

• Des traitements qui tournent seuls, la nuit. Une synchronisation trop longue pour la patience d'un navigateur, une file d'envois à préparer, un contrôle quotidien de ce qui a changé. Nous en avons documenté une trentaine sur un seul projet : chacun avec son heure, sa fréquence et ce qu'il faut faire s'il ne tourne pas. Un traitement sans personne devant doit savoir dire ce qu'il a fait et prévenir quand il échoue, plutôt qu'échouer en silence : nous l'écrivons ainsi, et nous convenons avec vous de qui reçoit l'alerte.
• Des courriels déclenchés par un événement, pas par un visiteur. Un dossier qui change d'état, une échéance qui approche, une date d'anniversaire. Personne ne clique : c'est la situation qui déclenche l'envoi.
• Des documents fabriqués par la machine. Facture, bon, carte, attestation, rapport. Avec la règle qui va avec : un document par personne et par an, et pas deux si on relance le traitement.
• Des passerelles entre vos outils. Votre logiciel métier, votre comptabilité, un service extérieur. Chacun sait faire son travail ; ce qui manque, c'est ce qui les relie, et c'est souvent ce que vous faites à la main aujourd'hui.

Comment nous travaillons

Une application métier rate rarement sur le code. Elle rate sur ce qu'on avait compris du besoin : les cas particuliers que personne n'avait mentionnés, ce qui doit se passer quand quelqu'un se trompe de bouton, la règle que tout le monde dans la maison connaissait sans jamais l'avoir écrite nulle part. Nous passons donc du temps avant la première ligne.

1. Nous écoutons, puis vous recevez un devis gratuit, qui dit aussi ce qu'il laisse de côté. S'il existe déjà un produit du marché qui fait l'affaire, nous vous l'indiquons à ce moment-là, même quand cela nous coûte le développement.
2. Nous écrivons ce que l'outil doit faire, règle par règle, dans un document que vous relisez. C'est là que se découvrent les exceptions, et il y en a toujours.
3. Nous modélisons vos données avant de coder. Ce que vous stockez, ce qui est lié à quoi, ce qui doit rester après cinq ans et ce qui doit disparaître avant. Quand l'outil porte des données de personnes, la durée de conservation et les droits d'accès sont des décisions à prendre à ce moment-là, pas après : nous vous disons lesquelles vous concernent. Une donnée mal posée au départ, on la traîne ensuite, et la reprendre quand l'outil est en service demande bien plus de travail qu'au moment de la concevoir.
4. Vous utilisez l'outil sur un environnement de test pendant qu'il se construit, et vous nous dites ce qui ne correspond pas. C'est plus efficace qu'une démonstration en fin de parcours.
5. Nous mettons en service, nous reprenons les données prévues au devis, et nous prenons le temps de former ceux qui vont s'en servir tous les jours.

Reste une question que vous vous posez peut-être : que devient cet outil si nous ne sommes plus là pour le suivre ? Nous y répondons par la façon d'écrire. Nous travaillons dans un cadre répandu et documenté, avec la structure qu'il impose, une base de données lisible et aucun outil qui nous soit propre. Un développeur qui ne nous connaît pas peut ouvrir ce que nous avons écrit et s'y retrouver.

Vous avez un besoin en tête mais pas encore de cahier des charges ? C'est justement par là qu'on commence.

Ce qui fait varier le prix

Il n'y a pas de grille tarifaire pour ce genre de travail. Les éléments qui suivent sont ceux que nous regardons pour chiffrer, et ils vous permettront de situer approximativement où se trouve votre projet.

• Le nombre de règles à respecter, et surtout le nombre d'exceptions à ces règles. C'est ce qui fait la longueur du travail, bien plus que le nombre d'écrans.
• Les données déjà là, leur volume et l'état dans lequel elles sont.
• Le nombre d'outils à raccorder, et surtout la qualité de ce qu'ils acceptent de vous donner. Un logiciel qui expose proprement ses données coûte beaucoup moins cher à brancher qu'un logiciel qui ne prévoit rien.
• Le nombre de personnes qui s'en servent, et le fait qu'elles aient ou non des droits différents.
• Ce qui doit tourner sans personne : un traitement de nuit demande à être surveillé, et à savoir quoi faire quand il échoue.

Lequel de ces cinq éléments pèse le plus chez vous ? Dites-le-nous, nous vous dirons ce que cela change.

Une application ne s'arrête pas à la livraison

Une application métier vit. Le socle sur lequel elle repose évolue, les services auxquels elle se raccorde changent leurs règles sans toujours prévenir, et votre propre activité bouge, ce qui suffit à rendre caduque une règle qu'on croyait acquise pour des années. C'est la différence la plus coûteuse avec un site, et elle se prépare.

Deux demandes très différentes arrivent sous la même phrase, « il faudrait changer ça ». Quand l'outil ne fait pas ce qui avait été convenu, nous le corrigeons. Quand l'usage fait naître une idée qui n'était pas prévue, c'est une évolution, et nous la chiffrons.

Le suivi dans la durée fait l'objet d'un contrat distinct du développement, établi sur la base de ce qui a été construit. Nous en parlons au moment du devis, et non un an plus tard.

Une réserve, qui a sa place ici plutôt que dans un contrat. Quand le socle change de génération, votre logique métier ne bouge pas, mais ce qui la porte, oui. Ce portage est un chantier à part, avec son propre devis. Ces échéances sont connues longtemps à l'avance, et il y a largement le temps d'en parler avant qu'elles arrivent.

Quand ce n'est pas une application qu'il vous faut

Tout ne mérite pas d'être écrit. Si votre besoin tient dans des pages à publier, c'est un site qu'il vous faut. S'il s'agit d'ajouter une fonction à un site qui existe déjà et qui tourne bien, c'est souvent un composant sur mesure, moins cher et plus simple à vivre qu'une application séparée.

Pour une passerelle, la question n'est pas ce qu'elle transporte, c'est où vit le traitement. Si c'est votre site qui doit recevoir ou publier ces données, elle a sa place dans le site. Si le traitement doit tourner à son propre rythme, pour d'autres personnes que les visiteurs, et que le site n'est qu'un de ses correspondants, alors c'est une application.

Nous tranchons cette question dès le premier entretien, parce qu'une fois le travail lancé, revenir en arrière coûte beaucoup de temps à tout le monde. Et si vous êtes dans la région de Charleroi ou en Hainaut, ce premier entretien peut se tenir chez vous.

Nous travaillons principalement en Symfony et PHP, en Node.js pour les services d'interface, avec des API REST et des bases MySQL, PostgreSQL ou SQL Server selon ce à quoi il faut se raccorder. Symfony, Node.js®, MySQL, PostgreSQL et SQL Server sont des marques de leurs détenteurs respectifs.