Comment je travaille
Quatre étapes. Pour chacune : ce qui est produit, et en combien de temps. Un seul interlocuteur du premier appel à la mise en ligne — celui qui écrit le code est celui qui répond au téléphone.
- 1
Cadrage — appel de 20 min, gratuit
On vérifie que le besoin est clair et que je suis la bonne personne. Vous décrivez le process qui coince, je pose des questions, et je vous dis honnêtement si c'est dans mes cordes.
Il arrive que la réponse soit non — parce qu'un logiciel du marché fait déjà le travail, parce que le sujet est d'abord une question d'organisation, ou parce que le budget et l'ambition ne se rejoignent pas. Autant le savoir en 20 minutes.
Ce que vous en retirez : une réponse claire, et un périmètre à écrire si on continue.
- 2
Audit — 4 à 5 jours
Un entretien sur place avec les personnes qui vivent le process, puis 2 à 3 jours d'analyse, puis une restitution de 45 minutes.
Vous repartez avec un document exploitable, même si on ne travaille pas ensemble ensuite : il est rédigé pour pouvoir être remis à quelqu'un d'autre.
Ce que vous en retirez : un document de 10 à 15 pages, le chiffrage du temps consommé et 5 à 8 recommandations priorisées.
Le détail de l'audit - 3
Développement — par itérations
Le projet avance par blocs, avec une version consultable à chaque étape. Vous voyez avancer, vous n'attendez pas la livraison finale pour découvrir le résultat.
Concrètement : à chaque itération, une adresse où le travail en cours est visible, et un point pour valider ce qui est fait et arbitrer la suite. Une remarque à ce moment-là coûte quelques heures ; la même remarque à la livraison coûte plusieurs jours.
Ce que vous en retirez : une version consultable à chaque étape, et aucune surprise à la fin.
- 4
Mise en ligne et suivi — recette, puis garantie
Recette : vous testez, sur la base de ce qui a été écrit au cadrage. Ce qui ne correspond pas est corrigé avant la mise en production.
Mise en production, puis période de garantie : les correctifs sur ce qui a été livré sont pris en charge. Ensuite, la maintenance est optionnelle — mises à jour, corrections, petites évolutions. Vous n'y êtes pas obligé, et le code reste le vôtre dans tous les cas.
Ce que vous en retirez : un projet en production, une période de garantie, et le choix de continuer ou non.
Si le besoin change en cours de route
Il change presque toujours. On comprend mieux un besoin en le voyant prendre forme qu'en le décrivant sur le papier, et une demande nouvelle en cours de projet n'est pas un problème : c'est le signe que le sujet avance.
Ce qui pose problème, c'est de ne pas savoir ce que ça change. Alors chaque ajout hors du périmètre écrit passe par un avenant : ce qui est ajouté, ce que ça coûte, ce que ça décale sur la date de livraison. Vous validez avant que je développe.
Concrètement, ça veut dire deux choses. La première : rien n'apparaît sur la facture finale sans que vous l'ayez accepté par écrit avant. La seconde : je ne fais pas semblant d'absorber gratuitement une demande qui représente trois jours de travail, parce que c'est exactement comme ça qu'un projet se dégrade — le prestataire rogne, la qualité baisse, et personne n'ose le dire.
Ce que je ne promets pas
Une astreinte 24/7
Je suis seul. Je réponds aux incidents dans la journée ouvrée, pas à 3h du matin.
Une position dans Google
Je traite ce qui dépend de moi : structure, performance, balisage. Le classement ne se garantit pas.
Un délai annoncé avant le cadrage
Une date donnée avant d'avoir écrit le périmètre est une date qui ne sera pas tenue.
Un process qui vous fait perdre du temps ?
20 minutes au téléphone pour en parler : ce qui coince, ce qui est traitable, et par quoi commencer. Gratuit, sans engagement, et sans devis à la clé si ce n'est pas justifié.