Facturation traitement post-rendu ?

Salut tout le monde,

Indépendante depuis peu, j'ai fini mon premier vrai contrat y a un peu plus de 10 jours. Il s'agissait de terminer le projet abandonné par un développeur peu scrupuleux. Jusque là aucun soucis. Le site était une merde sans nom, mais j'ai pu me débrouiller quand même pour faire ce que je devais (et un peu plus d'ailleurs) : pas de p, de h1, de a (juste des div et des span onclick), une mise en page parfois en tableau, parfois en div,...
Mais là n'est plus mon soucis...

Je devais programmer ça sans accès au serveur d'origine, en ayant tout juste son phpinfo(). Ce que j'ai pu faire, le rendu a été testé par la personne ayant passée commande sur mon serveur, sans le moindre bug.

J'ai donc rendu le projet y a 10 jours à la personne qui a passé commande qui devait le transmettre à son service technique. J'avais joint un lisez-moi.txt qui me semblait clair, pour permettre la mise en prod'.

C'est depuis qu'on enchaîne les soucis. La personne est venue me voir affolée, son site se servait de ma base de données (et pas des siennes); une des nouvelles fonctionnalités qui ne marchent plus du tout, puis aujourd'hui encore une autre.

Bien sûr, on me demande de débugger (je leur ai gentiment expliqués que ça risquait d'être dur sans accès au serveur, je m'appelle pas Majax), alors qu'il est pour moi manifeste que c'est le technicien qui n'a pas été fichu de suivre mes instructions. (à commencer par la modification des données de connexion à la base de données; le second bug vient à 90% de chances d'une table mal insérée,...)


Bref, ma question va paraître bizarre... Mais vous prévoyez ça comment les interventions de débuggages qui touchent à votre code APRES la fin de votre contrat ?
Mon contrat prévoyait juste la livraison des fichiers dans un .zip avec un fichier txt décrivant la procédure d'installation.
Vous incluez dans la facture de base un supplément pour "débuggage" éventuel ? Vous faites une nouvelle facture ?

Lothindil a écrit :

Bref, ma question va paraître bizarre... Mais vous prévoyez ça comment les interventions de débuggages qui touchent à votre code APRES la fin de votre contrat ?
Mon contrat prévoyait juste la livraison des fichiers dans un .zip avec un fichier txt décrivant la procédure d'installation.
Vous incluez dans la facture de base un supplément pour "débuggage" éventuel ? Vous faites une nouvelle facture ?

Sauf mention spécifiques dans un contrat, un prestataire a le devoir de livrer un produit conforme à la demande. Durant une certaine durée, les corrections de bugs touchant le fonctionnement demandé ne sont donc généralement pas facturables (pour l'exactitude des durées et les détails en France je ne peux répondre, je suis en Suisse , mais vous avez bien une "obligation de délivrance conforme" qui demande cela).
Pour moi cela est facturé avec d'autres détails qui se font par gonflement du tarif horaire. Les heures de maintenances prévues pour après la mise en prod concernent des demandes d'améliorations et de changements, les mises-à-jour, la maintenance pour les contraintes nouvelles, etc.

Les problèmes liés à la mise en production sont liés à celui qui en a le mandat (peut être éventuellement remis en cause dans le cas de procédures pas ou mal documentées).

Le débuggage de la mise en production peut donc être facturé en plus, vu que ce n'était pas prévu. Pour l'accès au serveur, il est parfois envisageable de se déplacer et de travailler avec le service technique interne.

Par contre, il n'auraient pas dû pouvoir se connecter à ta base de donnée, ces données auraient dû être supprimées/anonymisées dans la version transmise, pour justement éviter ce genre de problèmes. Mais ce n'est pas là un problème légal, plutôt une question de bonne pratique. (Par exemple stocker ces informations dans un fichier de settings, ne pas le versionner et prévoir une copie anonymisée)

kustolovic a écrit :

Par contre, il n'auraient pas dû pouvoir se connecter à ta base de donnée, ces données auraient dû être supprimées/anonymisées dans la version transmise, pour justement éviter ce genre de problèmes. Mais ce n'est pas là un problème légal, plutôt une question de bonne pratique. (Par exemple stocker ces informations dans un fichier de settings, ne pas le versionner et prévoir une copie anonymisée)

+1

Faut être un peu à la ramasse pour transmettre les identifiants de sa propre base de données à un tiers. Lothi, t'avais passé quelques nuits blanches à l'approche de la livraison ?

Sinon, dans la dernière boite où j'étais on facturait un support de x mois (entre 1 et 6 selon la taille du projet) après la mise en prod pendant lequel on intervenait sur le site si un problème lié à notre développement était découvert par le client. Le contrat stipulait que si un développeur externe à notre société intervenait sur le code, le support était stoppé.

Dans tous les cas c'était toujours nous qui étions chargé de la mise ne prod sur les serveurs des clients avec un contact direct avec leurs administrateurs système et équipes techniques.
Modifié par jb_gfx (12 Dec 2013 - 15:32)

kustolovic a écrit :
Les problèmes liés à la mise en production sont liés à celui qui en a le mandat (peut être éventuellement remis en cause dans le cas de procédures pas ou mal documentées).

Je pense qu'il m'était difficile de faire plus clair que :
dans le fichier xxx/xxx.php :
- ligne 8 : remplacer la valeur entre " " par l'IP du serveur de base de données
- ligne 9 : remplacer la valeur entre " " par l'utilisateur de la base de données
- ligne 10 : remplacer la valeur entre " " par le mot de passe de connexion à la base de données
- ligne 11 : remplacer la valeur entre " " par le nom de la base de données.

kustolovic a écrit :
Le débuggage de la mise en production peut donc être facturé en plus, vu que ce n'était pas prévu. Pour l'accès au serveur, il est parfois envisageable de se déplacer et de travailler avec le service technique interne.

Ca m'aurait fait des vacances, mais non, là c'était pas envisageable. (mon client est au Nord du Québec et moi en Belgique)



Et oui, il aurait pa dû pouvoir se connecter, mais j'avoue que la fatigue et l'euphorie de fin de projet aidant, j'ai zappé de changer les données de connexion. (sans impact par ailleurs, c'était pas une connexion à mes tables habituelles, mais un server de test où j'ai que des tests bidons).
J'ai d'ailleurs ajouté ça à ma check-list de fin de projets pour les prochains. (c'est le tout premier en pro...)


Et je note donc que c'est à comprendre dans mes tarifs la prochaine fois et à stipuler une durée de support.

a écrit :
Dans tous les cas c'était toujours nous qui étions chargé de la mise ne prod sur les serveurs des clients avec un contact direct avec leurs administrateurs système et équipes techniques.

J'aurais bien voulu... Mais là je me heurte à l'administration québécoise d'une école... En gros, je suis en contact avec la chargée de projet, qui transmet à la directrice, qui transmet au service informatique...

Lothindil a écrit :
]J'aurais bien voulu... Mais là je me heurte à l'administration québécoise d'une école... En gros, je suis en contact avec la chargée de projet, qui transmet à la directrice, qui transmet au service informatique...

Ils sont cantonné dans leur hiérarchie, pfff... Si ça peut te rassurer, c'est pas toujours comme ça. Perso, quand nous faisons affaire avec de l'externe, c'est avec moi directement qu'ils travaillent, pas mon chef de projet qui n'y connait rien.

Je suis curieuse de savoir avec qui tu as fait affaire...

Lothindil a écrit :

Je pense qu'il m'était difficile de faire plus clair que :
dans le fichier xxx/xxx.php :
- ligne 8 : remplacer la valeur entre " " par l'IP du serveur de base de données
- ligne 9 : remplacer la valeur entre " " par l'utilisateur de la base de données
- ligne 10 : remplacer la valeur entre " " par le mot de passe de connexion à la base de données
- ligne 11 : remplacer la valeur entre " " par le nom de la base de données.

Le problème c'est qu'avec internet les gens ne lisent plus. Il vaut mieux traiter directement au téléphone avec les personnes concernées pour toutes les étapes importantes de tes projets.

Lothindil a écrit :

Et je note donc que c'est à comprendre dans mes tarifs la prochaine fois et à stipuler une durée de support.

Oui, par exemple d'un mois après une livraison en bonne et due forme. Ensuite tu peux facturer en supplément un suivi à l'année si ton client le souhaite.

Concernant ta prestation, ça ne me parait pas honnête d’arrêter ton suivi au moment de la livraison sachant qu'il peut toujours y a voir des erreurs dans un développement informatique et ce d'autant plus que tu n'as pas accès au serveur de mise en production.
Modifié par bzh (12 Dec 2013 - 16:17)

bzh a écrit :
Le problème c'est qu'avec internet les gens ne lisent plus. Il vaut mieux traiter directement au téléphone avec les personnes concernées pour toutes les étapes importantes de tes projets.

Ce qui ne saurait se substituer à une trace écrite indiscutable de ces étapes importantes pour les ressortir en cas de litige, comme ça semble être le cas ici. Si les gens ne lisent plus c'est leur affaire : pour leur malheur, les professionnels sévissant dans les tribunaux de France et d'ailleurs portent quant à eux un amour inconsidéré aux belles lettres...

juliesunset a écrit :
Ils sont cantonné dans leur hiérarchie, pfff... Si ça peut te rassurer, c'est pas toujours comme ça. Perso, quand nous faisons affaire avec de l'externe, c'est avec moi directement qu'ils travaillent, pas mon chef de projet qui n'y connait rien.

Je suis curieuse de savoir avec qui tu as fait affaire...

J'ai eu affaire avec l'école d'une ami enseignante (en charge du projet "site web") ^^ -et oui, je sais, on travaille pas avec des amis, mais en l'absence de contrats, un contrat à 2500€, ça se refuse pas-.

Et traiter au téléphone, c'est une illusion sur ce coup-là. Même la directrice travaille par note avec le service informatique, donc bon... (enfin là ils sont entrain de négocier pour que je puisse être en contact direct, ne serait-ce que par écrit).

Et je comptais pas les lâcher, j'ai envie de dire que ça fait partie des aléas des premiers contrats et que c'est en se heurtant à des difficultés qu'on avance. C'était plutôt pour savoir comment gérer pour les prochains ^^

(et y a pas de litige -enfin pas encore-, la directrice a déjà eu des merdes avec le service informatique et elle, autant que l'enseignante, sont certaines que la faute vient de leur coté à eux -vu qu'elles ont vu le site chez moi qui marche nickel-)