Service

Application web sur mesure
au Québec

Un logiciel qui suit vos règles de métier au lieu de vous imposer les siennes. Conçu, écrit et mis en production par la personne à qui vous parlez.

Une application web sur mesure est un logiciel construit pour vos règles de métier et utilisé depuis un navigateur, sans installation. Je la conçois, je l'écris et je la mets en production seul, en Django, React et TypeScript. Vous parlez à la personne qui code, du premier écran jusqu'au premier utilisateur.

Le problème que ça règle

La plupart des entreprises n'ont pas un problème de site web, elles ont un problème de logiciel. Les commandes arrivent par courriel, quelqu'un les recopie dans un chiffrier, un deuxième chiffrier suit les stocks, et la facturation vit dans un troisième outil qui ignore les deux premiers. Ça tient tant que le volume reste petit. Le jour où il double, la journée de travail se remplit de recopiage, et les erreurs qui coûtent le plus cher sont presque toujours des erreurs de recopiage.

Les outils génériques règlent une partie du problème et en créent une autre. Ils imposent leur façon de nommer les choses, leur façon de découper un dossier, leur façon de calculer un prix. L'entreprise finit par plier son métier pour entrer dans le logiciel, puis paie un abonnement par utilisateur pour un produit dont elle se sert du quart. Quand elle demande le champ qui manque, la réponse est non, ou c'est une extension à acheter, ou c'est prévu pour un prochain trimestre.

Une application sur mesure prend le problème par l'autre bout. On part de ce que l'entreprise fait déjà, avec ses mots, ses étapes et ses exceptions, et c'est le logiciel qui se plie. Les données restent chez vous, le code aussi, et le champ qui manque s'ajoute le jour où vous en avez besoin plutôt qu'au calendrier d'un éditeur.

Ce que ce n'est pas

Un mandat mal orienté coûte plus cher à tout le monde qu'un mandat refusé au premier appel. Voici donc ce que je ne vends pas, et ce que je dis quand la demande ne colle pas avec ce que je sais faire.

  • Ce n'est pas un gabarit acheté et rhabillé. Si votre besoin se règle avec un site de présentation et deux extensions, je vous le dis au premier appel plutôt que de facturer trois mois pour refaire ce qui existe déjà.
  • Ce n'est pas une agence. Il n'y a pas d'équipe derrière moi, pas de sous-traitance à l'étranger, pas de chargé de projet qui fait le relais. J'écris le code moi-même, donc je prends peu de mandats lourds en parallèle, et je le dis quand mon calendrier est plein au lieu d'étirer le vôtre.
  • Ce n'est pas un service de garde. Je corrige ce que je livre, mais je ne vends ni astreinte de nuit ni garantie de réponse en quelques minutes. Une entreprise dont la production s'arrête à trois heures du matin a besoin d'une équipe, pas d'une personne.
  • Ce n'est pas une application mobile native. Je construis pour le navigateur, téléphone compris. Une vraie application iOS ou Android publiée dans les magasins se code autrement, et je ne vais pas prétendre le contraire pour décrocher le mandat.
  • Ce n'est pas un forfait chiffré sur une idée. Tant que les règles de métier ne sont pas écrites noir sur blanc, un prix ferme n'est qu'un pari, et c'est le client qui le paie. Je chiffre après avoir compris, jamais avant.

Ce que vous recevez

Le livrable n'est ni une maquette ni un rapport. C'est un logiciel qui tourne, avec ce qu'il faut autour pour qu'il continue de tourner le jour où je ne suis plus au dossier.

  • Une application utilisable depuis un navigateur, sur ordinateur comme sur téléphone
  • Les écrans de votre métier : saisie, suivi, recherche, exports
  • Un espace d'administration pour votre équipe, avec des droits par rôle
  • Une base de données PostgreSQL exportable, dont le contenu reste le vôtre
  • Les intégrations qui évitent la double saisie : paiement, courriel, API des outils déjà en place
  • Le dépôt de code à votre nom, avec l'historique complet des modifications
  • La mise en production, les sauvegardes automatiques et la documentation pour reprendre le projet sans moi

L'outillage reste le même d'un projet à l'autre. Une pile réduite se maintient et se transmet ; une pile choisie pour être à la mode se paie deux ans plus tard, quand plus personne ne veut y toucher.

  • Django
  • React
  • TypeScript
  • PostgreSQL
  • Celery
  • Redis

Comment ça se passe

Toujours dans cet ordre, et vous voyez sortir quelque chose de chaque étape. Personne ne disparaît trois mois pour revenir avec une surprise.

  1. Comprendre avant d'écrire une ligne

    Un appel, puis une lecture de ce qui existe déjà : vos chiffriers, vos courriels type, vos cas particuliers. Je cherche surtout les règles que personne n'a jamais écrites parce que tout le monde les connaît. C'est l'étape qui décide de tout le reste, et c'est celle que la plupart des devis sautent.

  2. Découper en tranches livrables

    On ne construit pas l'application entière avant de la montrer. On choisit la partie qui fait le plus mal, on la livre en premier, et vous vous en servez pendant que le reste avance. Une tranche qui sert vaut mieux qu'un plan complet qui attend.

  3. Écrire le code

    Django pour les règles de métier, les droits d'accès et les données, React et TypeScript pour les écrans. Vous suivez l'avancement sur un lien de préproduction que vous pouvez ouvrir n'importe quand, pas dans un rapport d'étape.

  4. Mettre en production

    Déploiement, sauvegardes automatiques, surveillance des erreurs. La mise en ligne est un jour ordinaire et pas un saut dans le vide, parce que le même code tourne déjà depuis des semaines sur une préproduction identique.

  5. Corriger, puis passer la main

    Les premières semaines d'usage réel révèlent toujours des choses que personne n'avait vues. Je corrige. Ensuite, soit on continue par petites tranches, soit vous repartez avec le dépôt et la documentation et ça s'arrête là. Les deux me vont.

Ce que ça change une fois en ligne

La première chose qui change est bête : la double saisie disparaît. Une commande entre une fois et sert ensuite au suivi, à la facture et au rapport de fin de mois. Le temps récupéré ne se voit sur aucune capture d'écran, il se voit sur la fin de journée de la personne qui recopiait.

La deuxième est plus lente à venir. Quand les données d'une entreprise vivent au même endroit, on peut enfin poser des questions qui n'avaient pas de réponse : quel produit se vend sans jamais revenir en garantie, quel client demande trois fois plus de suivi que les autres, combien de dossiers restent bloqués à la même étape depuis deux semaines. Un chiffrier ne répond pas à ça. Une base de données bien découpée répond en une requête.

Sous le capot, je travaille avec un jeu d'outils réduit et éprouvé, parce que la variété coûte cher à maintenir. Django tient les règles de métier, les droits d'accès et l'espace d'administration. PostgreSQL tient les données. React et TypeScript tiennent les écrans, et TypeScript sert surtout à ce qu'une erreur se voie à l'écriture plutôt qu'un mardi soir en production. Quand un traitement est trop long pour se faire pendant qu'un utilisateur attend, Celery et Redis le sortent de la requête et le font tourner à côté : c'est ce qui permet d'envoyer des centaines de courriels, de générer des documents ou d'appeler une API lente sans figer l'écran de personne.

Ce choix n'est pas théorique. LocaSur repose sur Django, Celery et Redis parce qu'une place de marché entre locataires et propriétaires traite en continu des tâches qui n'ont aucune raison de bloquer l'utilisateur. Find It Now ajoute des connexions temps réel pour qu'un objet retrouvé prévienne son propriétaire à l'instant où le code est scanné. Send Me Now encaisse de vrais paiements. Ce sont des applications en ligne, que vous pouvez ouvrir et essayer, pas des maquettes.

Ce que le projet demande de votre côté mérite d'être dit avant de commencer : quelqu'un chez vous doit pouvoir répondre aux questions de métier et trancher. Pas tous les jours, mais dans la semaine. Les projets qui traînent ne traînent presque jamais pour des raisons techniques, ils traînent parce que la question posée le mardi trouve sa réponse trois semaines plus tard et que la moitié du travail attend derrière.

Une application vit, enfin, et c'est la partie que les devis oublient. Les règles changent, un fournisseur modifie son API, un usage apparaît que personne n'avait prévu. J'écris donc pour que ça se modifie : des tests là où une erreur coûterait cher, un dépôt propre, une documentation qui explique les décisions et pas seulement le code. Le jour où vous confiez le projet à quelqu'un d'autre, cette personne doit pouvoir travailler sans m'appeler.

Ce que j'ai construit

Des applications en ligne, que vous pouvez ouvrir et juger vous-même. J'ai écrit le code de chacune, du premier écran à la mise en production.

Le reste est sur la page des réalisations.

J'écris aussi sur la façon dont ces applications sont faites :

Questions fréquentes

Combien coûte une application web sur mesure ?
Ça dépend de ce que l'application doit faire, et l'écart entre deux projets est énorme. Un outil interne qui remplace un chiffrier et une plateforme qui encaisse des paiements ne demandent pas le même travail. Je chiffre après avoir compris le besoin, sur la base des fonctions à construire, jamais à partir d'une grille de forfaits.
Combien de temps avant d'avoir quelque chose d'utilisable ?
Une première tranche qui sert vraiment se livre en quelques semaines. L'application complète se compte en mois. Le facteur qui allonge le plus les délais n'est pas le code : c'est le temps que met une décision à être prise de votre côté, ou un contenu à arriver.
À qui appartient le code ?
À vous. Le dépôt porte votre nom, l'historique complet vous suit, et la base de données s'exporte dès que vous le demandez. Vous devez pouvoir confier le projet à quelqu'un d'autre sans me demander la permission, sinon ce n'est pas un actif, c'est une laisse.
Pourquoi pas WordPress ou un outil sans code ?
Parce que ce sont de bons outils jusqu'au moment où votre règle de métier n'entre pas dans la case prévue. Tant que le besoin reste standard, un outil existant coûte moins cher et je le dis. Le sur-mesure commence là où l'empilement d'extensions devient plus fragile, plus lent et plus cher que du code écrit pour vous.
Qui va travailler sur mon projet ?
Moi, du premier appel à la mise en production. Pas d'intermédiaire, pas de sous-traitance, pas de chargé de projet qui traduit vos phrases à un développeur qui ne vous a jamais parlé.
Est-ce que vous reprenez une application déjà commencée ?
Oui, à deux conditions que je vérifie avant de dire oui : que je puisse faire tourner le projet sur ma machine, et que le code soit lisible. Si la reprise coûte plus cher que la reconstruction, je le dis, avec les raisons, et vous tranchez.
Est-ce que ça fonctionne à distance ?
Oui, c'est le mode par défaut. Je suis à Jonquière, au Saguenay, et je travaille avec des clients ailleurs au Québec, au Cameroun et en France. Les rencontres en personne restent possibles dans la région, le reste se fait en visioconférence et par écrit.

Voir aussi : Automatisation et agents IA, Refonte de site web. Tous mes services.

Parlons de ce que vous voulez construire

Le premier appel sert à savoir si le sur-mesure est la bonne réponse à votre problème. Si ce n'en est pas une, je le dis, et vous aurez perdu une demi-heure plutôt qu'un budget.

tokamdarius@gmail.com