Questions fréquentes

Tout simplement, avec vos mots à vous.
J'ai besoin qu'on échange, pour faire connaissance et découvrir votre projet. Une fois le périmètre défini, je vous fais une proposition chiffrée et détaillée.

On verra la partie technique ensuite.

1. Je commence par un audit technique pour cartographier l’existant, identifier les fragilités et documenter le code.
2. Ensuite, nous décidons ensemble : correction progressive, refonte ciblée ou reconstruction.

• Le périmètre fonctionnel (nombre d'écrans, de rôles, de règles métier)
• Les intégrations (paiement, ERP, API tierces, IA)
• Le niveau de finition (back-office, permissions, audit, tests)
• La reprise de l'existant (migration de données, refonte)

Le bon réflexe pour gagner du temps : me décrire votre projet en 3 lignes, je vous réponds sous 48h. avec une première lecture et une fourchette honnête.

• Le forfait, je m'engage sur un périmètre, un prix et un délai. C'est le bon choix quand le besoin est clair, cadré, et qu'on peut définir ensemble ce qui est livré. Vous savez exactement ce que vous payez, je porte le risque de l'estimation. C'est le format que je privilégie pour les projets complexes : application métier, refonte, migration, API.
• La régie, vous payez le temps passé, à un taux journalier. C'est le bon choix quand le besoin est exploratoire : on ne sait pas encore où on va, on veut avancer par itérations, ou on a besoin d'un renfort technique sur une durée. Vous gardez la main sur les priorités, je m'adapte.

Le risque : le forfait sur un périmètre flou. Si le projet n'est pas "cadrable", soit on part en régie, soit on prend 2 semaines de plus pour transformer le flou en forfait.

• A la demande (interventions ponctuelles). Un bug, une mise à jour, une petite évolution ? Je facture au temps passé, à un taux horaire ou journalier. Pas d'engagement, pas d'abonnement. Vous payez à l'intervention.
  ➔ Pour les applications stables et peu critiques.
• Au forfait (abonnement mensuel). Un montant fixe qui couvre les mises à jour de sécurité, la surveillance, les sauvegardes, un volume d'heures pour les petites évolutions. Budget prévisible et temps de réponse garanti.
  ➔ Pour les applicatons critiques dont les arrêts coutent cher.

Dans tous les cas, rien n'est figé : vous pouvez toujours changer si la formule ne vous convient pas.

Ca peut aller de quelques jours pour une landing page à plusieurs semaines pour un projet complet.
Dans tous les cas, un planning est inclus dans le devis avec des points d'étapes réguliers (sauf landing page).
Vous voyez concrètement l'avancée de votre projet.

Oui, à condition de découper.

On identifie ensemble le cœur du projet (ce sans quoi il ne sert à rien) ainsi que les priorités et on livre le plus urgent en premier. Le reste arrive ensuite, par itérations. Vous avez une version utilisable rapidement, et on enrichit sans tout casser.

• Interventions ponctuelles : quand vous avez un besoin précis (nouvelle fonctionnalité, correctif, optimisation). Vous payez à la demande.
• Abonnement maintenance : un forfait mensuel pour les mises à jour, la surveillance, les petites évolutions. Plus serein, plus prévisible.

On peut être en ponctuel et basculer en abonnement quand l'application devient critique. Ce n'est pas un engagement, c'est une assurance. Ce choix suit la maturité de votre projet.

Oui, c'est même l'objectif.

Une application Django bien conçue, c'est un back-office sur mesure : vous modifiez vos contenus, vos utilisateurs, vos paramètres, vos données, sans toucher au code.
L'interface est pensée pour l'utilisateur, pas pour un développeur.

Ce que vous ne gérez pas : les évolutions techniques (nouvelles fonctionnalités, mises à jour de sécurité, montées de version). Ça, ce n'est pas votre rôle mais c'est le mien (ou celui d'un prestataire).

Le lancement n'est pas une fin, c'est un début.

Les premières semaines servent à observer l'usage réel : ce qui fonctionne, ce qui coince, ce que les utilisateurs demandent. On ajuste. C'est normal, c'est même prévu.

• La maintenance : sécurité, sauvegardes, mises à jour, surveillance.
• Les évolutions : nouvelles fonctionnalités, optimisations, intégrations.

Vous décidez pour la suite : soit vous avez les ressources en interne, soit on continue ensemble, soit vous passez par un autre prestataire.

Répartition claire :

• Vous : contenu, utilisateurs, paramétrage métier, décisions produit.
• Moi (ou un prestataire) : évolutions, corrections, sécurité, performance, sauvegardes, mises à jour.

Le piège classique : croire qu'on sera autonome sur tout. Personne ne l'est, pas plus sur WordPress que sur Django. La différence, c'est que sur Django, la frontière est nette : vous êtes autonome sur le métier, le développeur s'occupe de la technique.

Vaste sujet !

Si par "vibe-coding", vous entendez "laisser une Intelligence Artificielle coder tout le projet de A à Z et livrer directement le résultat au client pour pouvoir le facturer le plus vite possible" alors non, ce n'est pas en accord avec mes valeurs.
Dans tous les cas, il faut se méfier d'un code livré trop rapidement ou pour un prix trop bas. Alors oui, "ça marche" mais bien souvent, le revers de la médaille, on le découvre quand c'est trop tard !

J'ai une approche pragmatique et assez critique vis-à-vis de l'IA.
Si l'IA permet effectivement de gagner en productivité, le risque est de se laisser conduire et de ne plus maîtriser le projet. Comme n'importe quel outil, il faut connaitre ses forces et ses faiblesses pour l'utiliser de la meilleure manière.

En toute transparence, j'utilise régulièrement l'IA. Pas dans le seul but de gagner du temps ni pour tout faire à ma place mais surtout pour livrer un code le plus stable possible.

Mais c'est un sujet passionnant, je suis disponible pour en parler plus en détail.