# Quand faire appel à un développeur n’a pas de sens

> Une partie des projets qui m’arrivent n’ont pas besoin de moi. Vingt produits sans déclinaison, un catalogue standard, aucun logiciel métier à connecter : une offre hébergée du marché fait le travail pour le prix d’un jour de développement. Le dire coûte des missions, mais moins qu’un projet livré à perte et abandonné six mois plus tard.

- Source canonique : [https://allaux.fr/creation/quand-un-developpeur-est-inutile](https://allaux.fr/creation/quand-un-developpeur-est-inutile)
- Langue : FR
- Dernière mise à jour : 2026-08-02

## Sept situations où vous n’avez pas besoin d’un développeur

- Moins d’une cinquantaine de produits, sans déclinaison ou avec deux ou trois options simples. C’est exactement le format que les offres hébergées gèrent le mieux, et sans aucune administration serveur.
- Un seul transporteur, un seul taux de TVA, une seule zone de livraison. Le paramétrage natif suffit partout, et il ne demande pas d’intervenant.
- Aucun logiciel de gestion, aucune caisse, aucun entrepôt à synchroniser. Les intégrations sont la première vraie raison de développer ; sans elles, il n’y a rien à écrire.
- Personne en interne pour administrer un serveur, appliquer des correctifs ou surveiller des sauvegardes. Une plateforme auto-hébergée que personne n’entretient devient un site piraté, c’est une question de mois.
- Un besoin d’abord éditorial : présenter une activité, être trouvé localement, prendre des demandes de contact. La vente est secondaire, et un site de contenu classique fait mieux le travail.
- Un budget total inférieur à ce que coûte une journée de développement. Ce n’est pas un jugement : c’est une contrainte, et il existe des réponses correctes pour ce budget.
- Un projet dont personne ne sait encore s’il aura des clients. Valider la demande avec une boutique montée en quelques jours coûte moins cher que de découvrir l’absence de marché après un développement.

## Ce qu’un webmaster fait mieux que moi, et moins cher

Il existe une confusion utile à lever. Beaucoup de demandes formulées comme « je cherche un développeur » décrivent en réalité un besoin d’entretien courant : ajouter des produits, mettre à jour des textes, changer une bannière, publier une page, vérifier que les mises à jour passent, répondre quand un formulaire ne part plus.

Ce travail existe, il est utile, et il n’a rien à voir avec du développement. Un webmaster ou un intégrateur le fait mieux qu’un développeur, parce que c’est son métier et parce qu’il le facture au bon prix. Me demander de saisir des fiches produits revient à payer un tarif de développement pour un travail de saisie — et je le ferai moins bien, parce que ce n’est pas ce que je fais tous les jours.

Le développeur devient utile à un moment précis : quand le comportement attendu n’existe pas dans l’outil et ne s’obtient par aucun réglage. Avant ce point, il coûte cher pour rien. Après ce point, il n’y a pas d’alternative.

## Les cinq déclencheurs qui rendent un développeur utile

1. **Une règle métier qui n’existe nulle part** — Un prix calculé sur des dimensions saisies par le client, une remise qui dépend d’un historique, un transport facturé au volume plutôt qu’au poids. Aucun réglage ne produit cela, aucune extension du marché non plus quand la règle vous est propre.
2. **Une connexion à un système extérieur** — Logiciel de gestion, caisse, entrepôt, comptabilité, marketplace. C’est le motif le plus fréquent et le plus légitime : les données doivent circuler dans les deux sens, sans ressaisie et sans écraser ce qui compte.
3. **Un volume qui fait céder l’outil** — Un catalogue qui ralentit le back-office, une page de catégorie qui met plusieurs secondes, un import qui n’aboutit plus. À ce stade, ce n’est plus du paramétrage, c’est de l’optimisation de requêtes et d’index.
4. **Une panne que personne ne sait expliquer** — Erreur 500, commandes perdues, paiements qui n’aboutissent pas, site compromis. Il faut alors lire les journaux, la base et le serveur : c’est exactement ce pour quoi on appelle un développeur.
5. **Un empilement d’extensions devenu ingérable** — Quinze extensions qui se marchent dessus, dont personne ne sait ce qu’elles font. Remplacer l’empilement par du code compris et maintenu redevient à ce moment-là l’option la moins chère.

## Pourquoi j’écris cette page

> Parce qu’un projet mal dimensionné se termine mal des deux côtés. Le client paie une infrastructure qu’il n’utilise pas, s’épuise à l’administrer, et finit par abandonner un site qui fonctionnait techniquement. De mon côté, je livre un travail dont je sais qu’il ne servira pas. Écarter ces projets à l’entrée est plus honnête, et c’est cohérent avec le reste de ce site : j’annonce ce que je fais, et aussi ce que je ne fais pas.

## Pages liées

- **Coûts cachés des applications** — Le revers d’une offre hébergée : l’addition mensuelle qui monte fonction par fonction. ([/shopify/problemes/couts-caches-applications](/shopify/problemes/couts-caches-applications))
- **Acheter un module ou le faire développer** — Le même arbitrage, appliqué à une fonctionnalité isolée plutôt qu’à un projet. ([/modules/acheter-ou-faire-developper](/modules/acheter-ou-faire-developper))
- **Tarifs** — Ce que coûte une journée, pour situer le seuil dont parle cette page. ([/tarifs](/tarifs))
- **Maintenance et infogérance** — L’alternative à un développement : entretenir correctement ce qui existe déjà. ([/services/maintenance](/services/maintenance))

## FAQ

### Une offre hébergée du marché peut-elle vraiment suffire ?

Pour un catalogue standard, oui, et durablement. Ces plateformes gèrent le produit, le panier, le paiement, la livraison et la fiscalité courante sans aucune administration technique. Leurs limites apparaissent sur trois terrains précis : les règles de prix inhabituelles, les intégrations avec un logiciel existant, et la personnalisation profonde du parcours d’achat. Tant que vous n’êtes sur aucun de ces trois terrains, développer n’apporte rien.

### Est-ce risqué de commencer petit puis de migrer ?

C’est raisonnable, à condition de savoir que la migration se paiera. Ce qui la rend coûteuse n’est pas l’export des produits, c’est la reprise des adresses, des commandes et des comptes clients. Commencer petit reste presque toujours moins cher que de développer une boutique pour une activité qui n’a pas encore trouvé ses clients.

### Quel est le seuil à partir duquel un développeur devient rentable ?

Il n’y a pas de seuil en chiffre d’affaires, mais un seuil en nature de besoin. Le jour où vous décrivez un comportement qu’aucun réglage ne produit, ou où une ressaisie manuelle vous coûte plusieurs heures par semaine, le calcul bascule. Avant ce jour, le développement est une dépense sans contrepartie mesurable.

### Acceptez-vous les petits projets ?

Oui, quand ils sont bornés : une correction, une intégration, un module, une reprise ciblée. Ce que je refuse, c’est de vendre une boutique développée à quelqu’un pour qui une offre hébergée serait manifestement plus adaptée. Je préfère le dire au premier échange, quitte à ne pas travailler ensemble cette fois-ci.

### Comment savoir dans quelle catégorie je me situe ?

Écrivez ce que vous vendez, combien de références, combien d’options par produit, quels transporteurs, et quels logiciels doivent parler à la boutique. Si cette description tient en cinq lignes et ne contient le mot « spécifique » nulle part, vous n’avez probablement pas besoin d’un développeur aujourd’hui. C’est aussi la réponse la plus utile que je puisse vous donner.