Archives de catégorie : Software

(re)Passons aux choses sérieuses !

Donc la question, c’est quelle est la façon d’organiser un service web… comme un site marchand par exemple.

En particulier, comment traiter le coeur du service, c’est à dire les bases de données ?

Habituellement, on sépare le service web en « deux parties » :

• Le front-office : c’est la partie visible par les clients du service. Pour un service e-commerce, c’est le site marchand lui-même.
• Le back office : c’est donc tout le reste. En fait, le back office regroupe beaucoup de modules (suivant la taille des projets) : CRM, emailing, outils de tracking (business intelligence), lien vers le système logistique, …

Chaque partie à besoin de bases de données pour travailler.

Comment faire ?

• Faire une seule base, et brancher tous les modules sur cette base centrale ?
• Mettre une base par module, et développer des logiciels de synchronisation, pour que les données des différents modules soient cohérentes ?

En fait, il n’y a pas de réponse systématique, et il faut prendre en compte beaucoup de paramètres :

• En règle général, il vaut mieux que le front office ai sa propre base de données, que cette base de données soit exclusive pour le front donc. L’idée, c’est que rien ne doit impacter le front office, qui est le moteur business.
• On développe rarement les modules « à partir de rien » : on utilise un « framework » pour le front, un module type Sugar CRM pour le CRM, … Or, ces modules ont leurs propres bases de données.
• Un autre paramètre est le nombre d’Internautes utilisant le Front. A partir d’un certain volume, on n’a plus le choix, il faut une base spécifique pour le Front.
• Le prix bien sûr, prix des licences logicielles et prix des développements.
• En particulier, si on a plusieurs bases de données, la synchronisation entre ces bases devient le point clé. Il faut développer des modules de synchronisation, avec des stratégies (quand doit on synchroniser, sur quels évènements). Il faut également penser aux évolutions : les bases de données sont faites pour évoluer. Il faut des modules de synchro pour gérer les versions des bases.

Dans tous les cas, il faut penser cette architecture des bases de données avec soin, c’est l’épine dorsale de tout le système.

C’est une analogie intéressante, que je vous propose de creuser (c’est le cas de le dire).

Comme je l’ai souvent dit, le e-commerce est mis en œuvre via du logiciel : Front office, back office, suivi des commandes, emailing, … Tous ces composants sont mis en musique via des lignes de code…

Le logiciel est un artisanat neuf, et c’est sain de chercher des repères par rapport à des industries plus anciennes.

Donc le bâtiment.

Pour construire une maison, il faut faire d’abord un plan.

En fait, avant de faire le plan, il vaut mieux creuser le besoin : nombre d’enfants, souhaits (avoir le soleil le matin, …), budget, délais, …

Ensuite, un architecte va faire le plan donc, et il va y avoir plusieurs aller-retours entre l’architecte et le client.

Après, il faut de la patience, tout le monde le sait : on rentre dans la partie réalisation. Un architecte ou un maître d’œuvre va diriger les opérations, et coordonner les activités de plusieurs corps de métier : terrassier, maçon, platrier, électricien, plombier, menuisier…. Pendant cette phase là, on ne peut plus tout changer, et plus le projet avance, et moins on peut changer de choses.

La réussite du projet final tient sur plusieurs critères :

• L’intelligence de l’architecte, pour réellement comprendre les besoins et envies des clients, qu’ils n’expriment parfois pas clairement ;
• Le savoir faire de l’architecte, pour trouver les artisans bien adaptés au projet, et les faire travailler au bon moment ;
• Le savoir faire individuel de chaque artisan : même si le maçon fait un très bon boulot, si le peintre « salope tout », le résultat final sera décevant ;

Par contre, plus les « couches basses » font du bon boulot, et plus on peut rattraper les erreurs : si c’est le maçon qui fait du mauvais boulot, il n’y a pas grand chose à faire…

On peut dire tout ça pour le logiciel :

• Comme pour le bâtiment, un logiciel doit être conçu, il faut faire des plans ;
• Il faut faire ces plans en discutant avec le « client » (équipe e-commerce de la grosse entreprise, patron pour la petite entreprise, …) ;
• Il faut avoir un bon architecte (vous avez mes coordonnées 😉 ) ;
• Il faut ensuite être très patient, parce que pour monter tout ça, ça prend du temps ;
• Enfin, le résultat final est dépendant de la qualité des artisans, individuellement.

Mais voilà, le logiciel, ça s’appelle également du soft : on croit que c’est mou.

De plus, le marketing de certains acteurs du logiciel nous laissent croire qu’on peut tout faire, tout demander, n’importe quand, et que le logiciel s’adaptera.

On le sait tous : le nombre de projets ne respectant aucun de ces « fondamentaux » est effarant : on démarre sans plan, on change de plan tout au long du développement, on recrute les équipes sans vraiment « challenger » les compétences par rapport aux objectifs, le tout se faisant sans architecte !

On rentre ensuite dans une spirale infernale, qui creuse l’écart entre les équipes marketing ou management et les équipes techniques. Pour les « marketeurs », la technique coûte cher, ne produit rien de bon, avec des délais incroyables ;
Pour les tecky, les marketeurs changent d’avis tous les jours, imposent des délais irréalistes, et ne reconnaissent pas la valeur du travail fait.

Il y a du pain sur la planche !