Un client demande s'il peut réserver en ligne. Ou vous décidez que les devis doivent cesser de vivre dans votre boîte mail. Ou la comptable voudrait que le site parle au logiciel qui contient déjà les factures.
Le réflexe est de demander si le site en est capable, et c'est cette question qui mène à une refonte. La bonne question est sous laquelle des quatre formes la fonctionnalité doit arriver, parce qu'une seule de ces formes est du logiciel sur mesure et que les trois autres sont en général plus rapides, moins chères, et bien plus faciles à abandonner.
Quatre façons dont une fonctionnalité peut arriver#
Toute demande tombe dans l'une d'elles. Déterminer laquelle avant de demander un prix à qui que ce soit, c'est déjà l'essentiel du travail.
| La voie | Ce que c'est | Ce que cela coûte vraiment |
|---|---|---|
| Une extension existante | Quelqu'un l'a déjà construite et vous la configurez | Peu d'argent, plus le temps de comprendre quel flux de travail elle suppose |
| Un service hébergé que vous intégrez | La fonctionnalité tourne chez une autre société et s'affiche sur votre page | Un abonnement mensuel, vos données chez eux, et leur habillage |
| Une connexion par API | Votre site parle à un système que vous payez déjà | Un développeur une fois, puis presque rien, jusqu'à ce que l'autre côté change |
| Du code sur mesure | Construit autour de votre façon réelle de travailler | Le plus cher, et c'est la bonne réponse quand les besoins sont les vôtres |
Essayez-les dans cet ordre. Non parce que la première est la moins chère, même si c'est en général le cas, mais parce que le prix d'un mauvais choix augmente à mesure qu'on descend la liste. Une extension que vous regrettez se désinstalle en une minute. Du code sur mesure que vous regrettez, vous l'entretenez aussi longtemps que le site vivra.
Décrivez la fonctionnalité à voix haute sans nommer votre entreprise ni rien qui lui soit propre. Si la description tient debout, quelqu'un l'a déjà construite et votre travail est d'aller le trouver. Si une phrase sur deux a besoin de vos règles de prix, de vos équipes, de vos étapes de validation ou de votre vocabulaire, c'est à cela que sert le développement sur mesure.
Les huit demandes, et où chacune atterrit d'habitude#
Ce sont celles qui reviennent. La colonne du milieu est une valeur par défaut honnête plutôt qu'une règle, et celle de droite est ce qui fait basculer une demande au-delà.
| Ce que vous voulez | En général | Ce qui fait basculer vers le sur-mesure |
|---|---|---|
| Réservation en ligne | Une extension | Vrais plannings du personnel, acomptes, règles d'annulation, deux choses qui ne peuvent être réservées en même temps |
| Devis | Une extension de formulaire, puis une personne | Des prix qui suivent vos propres règles, des étapes de validation, des devis qui changent et dont il faut l'historique |
| Adhésions | Une extension | Des niveaux qui doivent rester cohérents avec quelque chose en dehors du site |
| Espace client | Une extension, si les données sont déjà dans WordPress | Les données vivent dans un autre système, ce qui en fait une intégration |
| Configurateur de produit | Une extension, pour des variantes simples | Des options qui se contraignent entre elles, un prix en direct, ce que votre atelier sait réellement fabriquer |
| Paiements | Une extension de passerelle | Acomptes, paiements partagés, versements à d'autres vendeurs, fiscalité inhabituelle |
| Automatisations métier | Un service d'automatisation | Quand le processus est l'entreprise elle-même et non une corvée à côté |
| Intégrations par API | Parfois un connecteur tout fait | La gestion des erreurs, les reprises, et décider quel côté l'emporte quand les deux divergent |
Un même motif traverse tout ce tableau. La partie visible de chaque fonctionnalité est presque toujours déjà résolue. Ce qui ne l'est pas, c'est l'ensemble des règles en dessous, et ces règles viennent de vous.
La réservation est celle qu'on rate le plus souvent#
Un formulaire de réservation, c'est un calendrier, une date, un nom et une adresse e-mail. Toutes les extensions font cela. Si c'est vraiment ce dont vous avez besoin, vous aurez terminé cet après-midi.
La disponibilité est la partie difficile, et elle est invisible de l'extérieur. Qui est qualifié pour cette intervention, lequel d'entre eux est libre, combien de temps cela prend, quel battement laisser après, quelle salle ou quelle machine cela occupe aussi, ce qui se passe quand quelqu'un annule la veille, si un acompte a été pris et quelle est votre règle pour le rendre. Rien de tout cela n'apparaît à l'écran. Tout cela est votre métier.
Le partage est donc net. L'interface de réservation est un produit standard, les règles de disponibilité sont à vous. Beaucoup d'entreprises trouvent une extension dont les hypothèses coïncident avec les leurs, et c'est un très bon résultat. Si les vôtres ne coïncident pas, admettez que vous achetez un moteur de règles en faisant semblant d'acheter un calendrier.
Devis et configurateurs sont le même problème#
Ils arrivent comme deux demandes distinctes et n'en font qu'une. Tous deux prennent un ensemble de choix et le transforment en prix, et dans les deux cas la difficulté est entièrement dans les règles.
Un configurateur dont les options ne s'influencent pas est un formulaire. Un configurateur où choisir une option en exclut deux autres, change le prix d'une troisième et devient impossible au-delà d'une certaine taille est un petit logiciel contenant votre savoir-faire de fabrication. Les devis fonctionnent pareil. Une grille de prix fixe est une page. Un prix qui dépend du volume, de la distance, de l'urgence et du client qui demande n'est pas une page.
Il existe une étape intermédiaire bon marché que presque tout le monde saute. Publiez les options, recevez la demande, et chiffrez à la main pendant un mois. Vous découvrirez quelles règles vous avez réellement plutôt que celles que vous croyez avoir, et une fois sur deux la version manuelle se révèle suffisante.
Les paiements ne sont presque jamais la partie sur mesure#
Celle-ci mérite une correction, parce que c'est là que les gens s'attendent à dépenser et ce n'est pas là que part l'argent.
Encaisser une carte est un problème résolu. Les passerelles fournissent des extensions, ces extensions prennent en charge la conformité à laquelle vous ne devriez pas vouloir toucher, et en connecter une relève de la configuration et non du développement. Ce qui est parfois sur mesure, ce n'est pas la façon dont l'argent circule mais le moment : un acompte maintenant et le solde à la livraison, un paiement partagé entre vous et un sous-traitant, un remboursement qui suit votre politique d'annulation au lieu du réglage par défaut de la passerelle.
Si votre demande de paiement est en réalité une demande de règles, dites-le au moment de demander un prix. Cela change ce qui sera construit, et cela change le chiffre.
Quand une extension est la mauvaise réponse#
Réutiliser d'abord est une valeur par défaut, pas une religion. Quatre signes que cette valeur par défaut ne s'applique plus :
- Vous configurez contre l'extension plutôt qu'avec elle, et les contournements ont commencé à avoir besoin de leurs propres contournements.
- Trois extensions doivent coopérer pour produire un seul résultat, et chaque mise à jour est un petit pari.
- Elle détient des données dont vous avez besoin ailleurs, et les récupérer veut dire exporter un tableur à la main chaque mois.
- Elle n'a pas été mise à jour depuis longtemps, et ce qu'elle touche relève du paiement ou des données personnelles.
Une extension, c'est du code que vous n'avez pas écrit qui tourne sur votre site, et chacune est une chose de plus à tenir à jour et une surface de plus à surveiller. Prenez une sauvegarde avant d'en installer une que vous ne connaissez pas. Si elle a besoin d'une ancienne version de PHP pour fonctionner, traitez cela comme un vrai coût et non comme un détail, et continuez de chercher.
Pourquoi ajouter une fonctionnalité n'est pas refaire le site#
La peur derrière la question initiale est qu'ajouter quelque chose oblige à repartir de zéro. Sur une vraie installation WordPress, ce n'est pas le cas, et la raison mérite d'être vue mécaniquement plutôt que crue sur parole.
Tout ce qui figure dans ces quatre voies arrive comme un ajout. Une extension s'installe à côté de ce qui existe déjà. Une extension sur mesure fait la même chose, écrite pour vous. Un type de contenu personnalisé ajoute une sorte de contenu que le site n'avait pas. Un gabarit change la façon dont un type de page s'affiche. Une intégration est un bloc sur une page. Un appel d'API est du code qui s'exécute quand quelque chose se produit. Aucun d'eux n'oblige à toucher aux pages que vous avez déjà publiées.
C'est pour cela que le travail arrive sur le site que vous avez déjà, sans migration, sans second site, et sans changer l'adresse que vos clients connaissent. C'est aussi pour cela que l'ordre décrit dans le guide de personnalisation tient. Générer, faire tourner l'entreprise, puis ajouter.
Réutiliser d'abord, construire ensuite#
L'état d'esprit tient en une ligne : achetez la version ennuyeuse, découvrez ce dont vous avez vraiment besoin, puis payez la différence.
- Écrivez le résultat, pas la fonctionnalité. « Les clients choisissent un créneau et j'arrête de perdre mes samedis au téléphone » est un résultat. « Un système de réservation » est une liste de courses.
- Allez le chercher. La plupart des résultats ont déjà trois ou quatre produits qui les visent directement.
- Faites tourner la version ennuyeuse pendant un mois, même quand la version ennuyeuse est un formulaire et une personne.
- Notez chaque endroit où elle a fait mal. Cette liste, et non votre idée de départ, est le cahier des charges.
- Demandez ensuite un prix sur la différence.
Un devis pour « un système de réservation » chiffre l'idée que quelqu'un d'autre s'en fait. Un devis pour « les quatre règles que notre formulaire actuel ne sait pas exprimer » chiffre la vôtre, et le montant est bien plus petit. Des besoins flous sont la raison habituelle pour laquelle un projet logiciel dérape, et c'est ici l'endroit le moins cher pour les rendre précis.
Cela protège aussi de l'erreur plus discrète, qui coûte tout autant. Payer un développement dont vous n'aviez pas besoin ne ressemble pas à une perte, puisque vous recevez bien quelque chose. Vous recevez quelque chose qu'il vous faut désormais entretenir. Le versant financier de ce partage est traité ici.
Partez d'un site qui accepte les quatre voies
Décrivez ce que vous faites et Sitebefy construit un vrai site WordPress qui vous appartient, avec les pages, les mises en page, le contenu et le SEO déjà en place. Comme c'est du WordPress ordinaire, une extension, un service intégré, une connexion ou une fonctionnalité développée sur mesure peuvent tous y arriver plus tard sans refonte. Regardez le résultat avant de créer un compte, et chaque formule est couverte par une garantie satisfait ou remboursé de 14 jours.
Créer mon siteLa prochaine fois qu'on vous demande une fonctionnalité#
- Dites le résultat à voix haute sans nommer votre entreprise. S'il tient debout, allez faire les magasins avant d'aller faire chiffrer.
- Donnez un vrai mois à la version ennuyeuse, avec une vraie sauvegarde prise avant d'installer quoi que ce soit.
- Tenez une note courante de ce qu'elle n'a pas su faire.
- Demandez un prix sur cette note plutôt que sur la demande d'origine.
Rien de tout cela ne plaide contre le fait de payer un développeur. Cela plaide pour savoir ce que vous lui payez, c'est-à-dire la partie de votre entreprise qui n'existe nulle part ailleurs. Le développement sur mesure commence ici par une description et un devis, et rien n'est construit tant que vous ne l'avez pas accepté : c'est donc dans la phase de cadrage que l'argent se gagne ou se perd.
Le site que vous avez n'est pas la contrainte. Il ne l'a jamais été. La contrainte, c'est la précision avec laquelle vous savez décrire la seule chose que vous faites et que personne d'autre ne fait, et cela vaut un après-midi bien avant de valoir une facture.
