Skyduino:~#
Articles
tutoriel

[Beta site v2] C’est la tuile

Bonjour tout le monde.

La beta du site v2 est en ligne depuis maintenant un peu plus de 48 heures. À ce stade, des correctifs de bugs devraient être en cours de déploiement sur le serveur. Et un article récapitulatif de cette première mise en ligne du site v2 devrait être en cours d’écriture. Il n’en est rien.

La vérité, c’est que depuis dimanche, jour de la mise en ligne de la bêta, je découvre de plus en plus de problèmes majeurs qui me poussent à revoir fondamentalement mon plan de bataille.
C’est un peu la douche froide pour moi. C’est même à la limite du Ice Bucket Challenge.

Et là, c’est le drame

Le problème ne vient pas de la mise en ligne du site à proprement parler.

Certes, il y a eu quelques imprévus qui ont un peu gâché la fête, en particulier avec les envois de mails depuis le serveur. À ce titre, je ne peux que déconseiller vivement quiconque d’utiliser une adresse hotmail, live ou outlook pour recevoir des emails importants. Pour faire simple, Microsoft a une politique antispam tellement stricte que vous avez la garantie de perdre des emails, spam ou non.

Le vrai problème vient du code du site. Je savais par exemple que le moteur de rendu HTML servant à transformer le texte saisi en HTML « propre et bien formé », affichable par la suite sur le site, était loin d’être parfait (très loin même). Ce que je n’avais pas prévu, c’est que celui-ci ne fonctionnerait tout simplement pas en situation réelle.
Je savais que des modifications du moteur de rendu HTML aller être nécessaires, mais pas une refonte complète.

Dans le même temps, en lisant les retours de bugs sur le site — merci à tout les bêta-testeurs au passage 😉 — j’ai pu découvrir plein de petits bugs, certains connus, d’autres non.
Séparément, ce sont tous des bugs relativement simples à corriger et sans grand impact sur le reste du site. Mais pris tous ensemble, cela fait une quantité de travail non négligeable pour l’écriture des correctifs.
S’ajoutent à cela les bugs découverts en corrigeant d’autres bugs … un vrai cycle sans fin.

Pour être tout à fait franc, il y a pas mal de bugs que j’aurai pu détecter et corriger avant la mise en ligne de la beta, en faisant des tests unitaires corrects.
Le problème, c’est qu’écrire des tests unitaires corrects ça prend du temps, beaucoup de temps et que le temps j’en manque cruellement malheureusement.

Au final, je suis arrivé à la conclusion qu’une revue du code dans son ensemble est plus que nécessaire.
Des choix techniques qui me semblaient parfaitement logiques lors du développement se sont finalement avérés extrêmement énervants en situation réelle.
Par exemple, l’idée d’avoir un historique de modifications des tickets de bug par commentaire à chaque changement me semble vraiment une idée stupide après coup.

Une grande partie du code du site est fonctionnelle et ne demande aucune modification (excepté peut-être quelques changements de design HTML).
Le problème c’est les quelques morceaux de code qui nécessitent un refactoring, voir carrément une remise à plat.
S’ajoute à cela le fait qu’il reste toujours la partie abonnements et boutique à mettre en place !

Un retard du code de base entraînera forcément un retard de la boutique et des abonnements, en plus d’un retard de la publication des articles (le temps que je passe à faire du code, je ne le passe pas à écrire des articles).
En tant que chef d’entreprise, un énième retard n’est pas envisageable. J’ai besoin d’un site pour commencer à gagner de l’argent.
D’un autre côté en tant que développeur, avec un peu plus de temps, je pourrai sans problème corriger tous les bugs et reprendre les morceaux de code qui posent problème.

Jusqu’à dimanche dernier, je réfléchissais en tant que développeur, mais maintenant je réfléchis en tant que chef d’entreprise.
Je ne sais pas si c’est les 30°C dans l’atelier qui me font réfléchir à tout ça, ou si c’est les 40 points à corriger dans ma TODO list.
Le fait est que je me demande si je vais dans la bonne direction.

Je suis fasse à un dilemme.
Soit je bouche un à un les trous dans la coque de mon bateau et j’en fais un vrai yacht de luxe, toutes options incluses.
Soit je passe au plan B qui consiste à utiliser un cargo, lent et pas franchement puissant, mais qui marche « out the box », pour faire mon site v2. En l’occurrence, le cargo en question ne serait rien de plus que WordPress, avec bbPress et WooCommerce.

Le seul souci du plan B (outre les divers aspects techniques), c’est que WordPress n’a jamais été conçu pour faire des sites avec abonnements. Au mieux, je vais payer une fortune pour un plugin comme Paid Membership, au pire, je n’aurai pas d’abonnements du tout.
Mais si je deviens une simple boutique de vente en ligne, doublée d’un blog et d’un forum, je vais obligatoirement devoir revoir ma façon de gérer/rentabiliser le blog. Et ça, ça me terrifie plus que tout.

Voilà où j’en suis actuellement. Tous les avis sont les bienvenues.

Si vous pensiez qu’il était impossible de passer de la joie, à la remise en cause complète, le tout en moins de 72h. Et bien voici la preuve que c’est possible.

En attendant, je vais me prendre une bonne douche froide (une vraie), sinon vous entendrez parler de moi aux infos quand on annoncera avoir retrouvé un jeune homme desséché devant son ordinateur.

PS Je confirme la rumeur comme quoi il est très déstabilisant psychologiquement d’expliquer à son entourage pourquoi on n’a pas encore de client. Pourquoi il faut plus de 9 jours pour ouvrir une boutique en ligne. Et pourquoi je n’ai pas fait le choix de trouver un emploi dans une grosse boite d’informatique en Californie.

Discussion

17 réflexions sur “[Beta site v2] C’est la tuile

  1. Bon courage, la dernière fois que j’ai fait un site, j’avais mal estimé le temps nécessaire qui me fallait pour terminer, et au final j’ai été en retard d’1 mois 1/2 (le retard n’était pas bien grave, c’était un travail semi-personnel) mais le fait est qu’il serait dommage de s’arrêter en si bon chemin et de se rabattre sur une solution que tu sais grandement pénalisante par la suite.
    Coté solution, peut-être devrais-tu chercher des devs qui accepterait de t’aider bénévolement, ou en échange de quelques années d’abonnement premium à ton site.

    Publié par pro_info | 9 juin 2015, 17 h 22 min
  2. Salut Fabien,
    Courage, il faut un minimum de temps pour que les choses se mettent en place.
    Eternel dilemme entre business et look.
    Pas assez de look et les prospects disparaissent
    Trop de business et les prospects ne restent pas
    Tu trouveras le juste équilibre pour démarrer ton activité
    A bientôt
    icare

    Publié par Icare Petibles | 9 juin 2015, 18 h 08 min
  3. La solution aux bugs et aux retards ? Le open source !
    Passe le code de ton site en open-source, ça permettra à tout le monde de corriger les bugs, de l’améliorer, et (surtout) de voire les failles de sécurité, d’où l’intérêt de faire un truc sécurisé.
    Je pourrai sûrement t’aider si les problèmes ne sont pas de l’ordre de la présentation (je sais faire de l’HTML, mais faire un truc beau from scratch …).
    En plus maintenant que ton site et up et que tout le monde connaît, ça sert plus à rien de nous le cacher 😉

    Publié par Firewolf | 9 juin 2015, 19 h 46 min
    • Heu non.

      Je nage dans l’open-source depuis plus de quatre ans maintenant et si il ya bien une chose dont je suis certain, c’est que l’open-source n’est pas une solution miracle aux bugs, retards, fonctionnalités manquante et défauts de sécurité.

      Dans un monde utopique ce serait le cas. Mais dans la vie réelle, l’open-source c’est avant tout un argument commercial pour te vendre un truc en disant que « c’est modifiable à souhait, blabla, toujours disponible même si on disparaît, blabla, support par la communauté, blabla ». Ou pire, une excuse pour pomper du code légalement et gratuitement.

      Malheureusement, pour le moment, l’open-source est surtout considéré par beaucoup comme du gratuit, pas comme du participatif.

      Publié par Skywodd | 10 juin 2015, 15 h 41 min
  4. J’ai eu cette même réflexion il y a quelques années, et finalement je me suis orienté vers un site wordpress avec un nombre limité de plugins. Ceci afin de consacrer le peu de temps libre que j’ai à la rédaction d’articles plutôt qu’à du debug et de la maintenance qui au final ne se voient pas pour le visiteur lambda. Ca me permet également de rester à jour au niveau référencement avec un SEO optimizer développé par des gens qui s’intéresse de près aux moteurs de recherches (Google change assez souvent d’algorithme de référencement). Personnellement je préfère passer plus de temps à travailler le contenu que le contenant.

    Pour ce qui est de WooCommerce, j’avais également choisi cette option là, mais le plugin a encrassé toute ma table d’utilisateurs WordPress et je n’ai jamais été satisfait du rendu final. Finalement, j’ai opté pour un Prestashop avec un design similaire dans un sous-domaine, afin de séparer la partie shop de la partie site (beaucoup plus pratique pour les maintenances).

    Je ne dis pas que c’est la meilleure solution mais c’est celle qui me convient le mieux, du coup je partage. Ayant mon entreprise depuis maintenant 5 ans, j’ai vite appris que la ressource la plus précieuse est le temps (madame l’a vite compris aussi).

    Bon courage!

    Publié par sebecam2000 | 9 juin 2015, 19 h 54 min
    • J’ai deux plan B :

      1) WordPress + forum (choix A bbPress, choix B fluxBB ou SMF) + ecommerce (choix A WooCommerce, choix B Prestashop)

      2) Drupal + module blog + module forum + module commerce (et une montagne de dépendances en plus)

      Avec le plan 1) je perd les abonnements … pas génial.
      Avec le plan 2) je conserve les abonnements … mais je fini avec un site sous Drupal … lourd, très lourd (et très lent).

      Dans les deux cas, je suis pas franchement satisfait. En plus, une grande majorité de mes attentes en terme d’expérience utilisateur passent à la trappe.

      Mon côté entrepreneur voudrais bien en finir avec le code et commencer à « vraiment » bosser.
      Mon côté dév lui voudrais bien reprendre le code de la beta pour faire un truc au top …
      L’idéal serait que je me dédouble … mais ce n’est pas (encore) possible 🙂

      Le pire cas serait que je prenne autant de temps à configurer/installer un trio blog/forum/boutique avec un thème unique qu’à reprendre le code de la beta. Là ce serait la grosse tuile :/

      Publié par Skywodd | 10 juin 2015, 15 h 52 min
  5. Pourquoi tu travaille pas pour une entreprise en californie? Ils ont plein d’info sur moi en plus.

    Publié par LaLoke | 9 juin 2015, 20 h 33 min
  6. As tu regardé du coté de CMS MS par exemple ? Facilement customisable , rapide efficace ça requiert juste PHP MySQL …

    Publié par Dj_Garfield | 9 juin 2015, 23 h 40 min
  7. Bonjour,
    je n’arrive pas à activer mon compte sur le site (et donc à créer un ticket de bug) : le texte « activer mon compte… » ne comporte pas de lien (viré par Gmail ?).
    Il faudrait prévoir permettre aux utilisateurs de recopier le lien dans leur navigateur comme c’est fait dans bcp de systèmes d’inscription…
    Sinon le site a l’air pas mal…la version mobile est bien pensée…
    Bon courage 😉

    Publié par Sebyg | 10 juin 2015, 8 h 05 min
  8. Allez Fabien , respire un grand coup et replonge dedans 😀
    C’est normal que tu ai des hauts et des bas quelquefois de forte amplitude sur ton moral.
    Tu te lance dans le grand bain de la vie d’adulte.
    Tu fais le bon choix de réfléchir correctement en ne te masquant pas les problemes.

    Publié par Artouste | 10 juin 2015, 11 h 36 min
  9. Salut Skywood,

    Réaliser un site web prend en effet beaucoup de temps et ton expérience me pousse d’ailleurs encore plus à ne pas m’y aventurer.

    Moi personnellement ce que j’aurais fait, c’est au départ monter le site avec un CMS Django en modifiant légèrement (ou peut-être beaucoup) le code de celui-ci pour intégrer les abonnements. Par la suite, une fois que j’aurai eu un peu plus d’argent, je payerai 5000 euros un intégrateur pour qu’il me fasse tout le frontend du site de A à Z et moi je n’aurais plus qu’à faire le background à l’aide de Django. Je ne dis pas que c’est la meilleure solution, mais qu’en penserais-tu ?

    Publié par texom512 | 15 juin 2015, 22 h 27 min
    • >> Réaliser un site web prend en effet beaucoup de temps et ton expérience me pousse d’ailleurs encore plus à ne pas m’y aventurer.

      Concevoir quelque chose prend toujours du temps, c’est inévitable.
      Si j’avais fait les choses correctement dés le début j’aurai surement déjà fini …

      >> Moi personnellement ce que j’aurais fait, c’est au départ monter le site avec un CMS Django en modifiant légèrement (ou peut-être beaucoup) le code de celui-ci pour intégrer les abonnements.

      J’ai envisagé cette solution, mais elle n’est pas faisable. Modifier le duo DjangoCMS/DjangoShop pour y intégrer une notion d’abonnements est peine perdue.
      Entre les morceaux de code compatible Python 2 et Python 3, les patchs de rétrocompatibilité pour django 1.6 et 1.5 … c’est impossible de comprendre comment marche ce CMS.
      J’ai aussi regardé Mezzanine/Cartridge, c’est encore pire que DjangoCMS/DjangoShop.

      >> Par la suite, une fois que j’aurai eu un peu plus d’argent, je payerai 5000 euros un intégrateur pour qu’il me fasse tout le frontend du site de A à Z et moi je n’aurais plus qu’à faire le background à l’aide de Django. Je ne dis pas que c’est la meilleure solution, mais qu’en penserais-tu ?

      Mouai. Pas sûr que ce soit la meilleure solution.
      Perso pour le moment, je suis en train de reprendre le code de la beta au propre.
      J’ai épuisé toutes les solutions de secours que j’avais.

      Publié par Skywodd | 3 juillet 2015, 15 h 29 min
      • « Mouai. Pas sûr que ce soit la meilleure solution. »
        Je ne vois pas quelle solution pourrait être meilleure, il me semble que c’est comme ça que font les grandes entreprises : ils ont des développeurs qui s’occupent du code et ils payent un seul homme mais extrêmement reconnu (et par conséquent très coûteux) pour faire la partie graphique. Pourquoi tu n’apprécies pas cette solution ?

        Publié par texom512 | 3 juillet 2015, 22 h 28 min
      • >> Je ne vois pas quelle solution pourrait être meilleure, il me semble que c’est comme ça que font les grandes entreprises : ils ont des développeurs qui s’occupent du code et ils payent un seul homme mais extrêmement reconnu (et par conséquent très coûteux) pour faire la partie graphique. Pourquoi tu n’apprécies pas cette solution ?

        Je ne sais pas où tu as vu que ça se passer comme ça dans les grandes entreprises 😉
        En général, c’est le sous-traitant avec les meilleurs arguments commerciaux (celui qui sait vendre les capacités de son entreprise et qui sait comment parler business avec le patron) qui remporte le contrat.
        Une entreprise qui se paye un graphisme reconnu, c’est en général pour pouvoir derrière vendre un produit « design by machin » 😉

        Publié par Skywodd | 9 juillet 2015, 11 h 27 min

Rétroliens/Pings

  1. Pingback: [Beta site v2] Plan D | Skyduino - Le DIY à la française - 11 juin 2015

  2. Pingback: [CarnetDuMaker] Nouveau système de comptes utilisateurs | Skyduino - Le DIY à la française - 10 juillet 2015

Skyduino devient Carnet du Maker

Le site Carnet du Maker remplace désormais le blog Skyduino pour tout ce qui touche à l'Arduino, l'informatique et au DIY.