1.04

CRM / SugarCRM - Partie 2

Publié dans , , | Aucun commentaire »

Voici donc la suite de mon billet sur le CRM et SugarCRM.

SugarCRM donc.

L’application permet, à la base, de gérer les données suivantes : Contact, Compte (regroupe plusieurs contacte), Affaire (associée à un Compte), Evènement (appel téléphonique, mail)…

Mais le modèle est particulièrement évolutif. Fondamentalement, le système permet de gérer… des données ayant des relations entre elles (on peut difficilement faire plus générique !). C’est pourquoi SugarCRM peut être utilisé pour des applications très variées, bien loin du modèle initial.

Autre sujet intéressant : comment brancher un site marchand sur le système de CRM ?

2 approches : on peut avoir les deux systèmes séparés, chacun ayant sa propre base de données.

Avantage : c’est propre, et les activités “back” ne viennent pas impacter ce qui se passe au niveau du Front.

Le problème est qu’il faut alors synchroniser les bases. Cette synchronisation va nécessiter un développement spécifique, qu’il faudra faire évoluer en permanence, pour des évolutions sur le front ou sur le back.

Autre solution : tout construire sur SugarCRM. Un client d’Ysance l’a fait, et ça marche très bien.

L’avantage est évident : un seul modèle de données, rien à synchroniser.

Problème ? Il faut être attentif à ce que les opérations du back n’impactent pas trop les performances du site. Cela va bien pour un site ayant un trafic “raisonnable”. C’est une bonne solution pour commencer, il sera toujours temps de faire évoluer le modèle.

31.03

CRM / SugarCRM - Partie 1

Publié dans , , , | 5 commentaires »

J’étais invité, l’autre jour, à une présentation de SugarCRM, organisée par Ysance (bravo Samuel).

Ysance connait très bien ce logiciel, pour l’avoir mis en œuvre dans de nombreux contextes.

CRM donc…

L’idée de base du CRM, c’est qu’il est plus rentable de cultiver les clients existants que de travailler à en ramener des nouveaux. Evidemment, il ne faut pas appliquer cette doctrine à la lettre : il est toujours bien d’aller chercher des nouveaux clients, mais celà nous rappelle qu’on peut travailler sur la base installée.

Travailler la base installée, cela veut nécessairement dire mieux travailler la relation avec ces clients.

La relation avec les clients, c’est :

  • La relation avant la vente, la relation durant la prospection donc ;
  • La relation pendant la vente ;
  • La relation après la vente, y compris le service après vente.

Une solution CRM, c’est une solution qui doit permettre de gérer l’ensemble des données et des processus liés à la relation entre l’entreprise et les clients.

SugarCRM est l’un des acteurs clé de ce marché, et le leader des solutions open-source.

SugarCRM commercialise différentes version de sa solution, et la version de base, déjà très complète, est gratuite. Les versions plus complètes sont payantes avec des prix somme toute raisonnables (de 275 $ à 450 $ par utilisateur et par ans).

Avoir une solution open source est important dans ce genre d’application. Par définition, cette application est au coeur du système d’information, et c’est donc important pour l’entreprise d’avoir la main sur le code source.

OpenSugar est une application écrite en PHP 5, utilisant une base de donnée (souvent MySQL, mais OpenSugar supporte d’autres bases).

Pour le e-commerce, le CRM est tout simplement vital !

La suite au prochain épisode !

28.03

Avancer vite, ou sécuriser ?

Publié dans , | Aucun commentaire »

Dans notre secteur, le e-commerce, une part importante des investissements est affectée au développement du système informatique : front-office et back office.

C’est un investissement important parce qu’il y a beaucoup de choses à développer : front, administration du front, gestion du processus de livraison, lien avec les systèmes des transporteurs, CRM, emailing, moteur de recherche, lien avec les plate-formes d’affiliation et moteurs de shopping, système de gestion du SAV, gestion du stock, …

Il n’existe pas de solution clé en main, couvrant tous les besoins. Il faut donc construire le système, à partir de différents composants, et réaliser les développements pour adapter ces composants au contexte de l’entreprise, et pour faire l’intégration entre les composants. De plus, l’activité e-commerce vient bien souvent compléter un système d’information déjà en partie construit : on arrive rarement en terrain vierge !

Comment font les entreprises pour développer leur système informatique ?

Plusieurs cas de figures bien entendu. Les grosses entreprises, ayant un gros système informatique, peuvent confier la mission de la mise en ligne d’un site marchand à l’équipe informatique. Dans ce scénario, on arrivera sans doute à un processus technique assez classique, avec cahier des charges, appel d’offre, …

Mais bien souvent, dans les petites structures, les moyens mis en œuvres seront beaucoup plus artisanaux : un développeur, et hop, le site est en ligne, avec bien souvent développement 100% maison.

Si le développeur est bon, le système peut marcher, et tenir quelques années : 2, 3, … 5 ?

C’est clairement le moyen le plus économique pour mettre en ligne un site marchand.

Le problème, c’est que tout l’édifice repose alors sur le savoir faire un peu magique d’un seul homme.

L’autre problème, c’est que l’entreprise aura une vision des développements très “particulière”, puisque “la toute petite équipe technique” fonctionne sur un mode complètement informel, et que le développeur peut ainsi faire des modifications très très rapidement.

Plus tard, quand les revenus deviennent important, d’autres aspects surgissent : la fiabilité, la sécurité, …

Il faut alors changer de méthode, mettre en place de la redondance, à tous les niveaux (hard, humain). Tout cela est infiniment moins rapide qu’avant !

Ah là là, que la qualité coûte cher !

25.03

Abstraction or not abstraction

Publié dans | 2 commentaires »

Le fondement même de la qualité, en matière de logiciel, passe par l’abstraction.

Si on veut écrire un logiciel apte à évoluer, on doit le concevoir sous la forme de modules.

Un module, c’est un ensemble de programmes, qui doivent résoudre un problème bien défini.

L’abstraction, c’est l’idée qu’on peut définir et programmer un module, sans aller voir dans les modules voisins : ceux avec qui les programmes discutes, a côté donc mais également en dessous.

Ainsi, quand on développe une application Windows par exemple, on a besoin de connaitre les API de Windows. Pas son fonctionnement intime.

Et bien actuellement, il me semble que cette idée est bien mise à mal. Quand on développe un service Internet, il est difficile de se positionner dans cette posture. Tout est incroyablement entre-mêlé.

Ainsi, pour mettre en ligne un service, qui va devoir supporter de grosses montée en charges, on doit tout prendre en compte, et avoir une culture qui mêle base de données, réseau, serveur Internet, …

C’est bien entendu une situation temporaire, qui met en avant la fragilité des architectures actuelles, et de la non maturité des solutions mises en oeuvre.

Ceci étant dit, il faut bien avancer et on doit faire avec !

17.03

Le futur des applications en ligne / Lancement d’AIR demain

Publié dans , , | 1 commentaire »

Demain soir a lieu le lancement officiel d’AIR d’Adobe (vous y serez ? Moi, oui !).

L’occasion de se reposer la question : quel est l’avenir des applications en ligne ?

On peut utiliser une application qui va se jouer dans le navigateur (un service Internet quoi).

Avantages :

  • L’utilisateur n’a rien à installer, donc un accès rapide à l’application, un accès depuis n’importe quel ordinateur, et pas de problème de mise à jour ;
  • On bénéficie de facto de toute les fonctions autour des URL (bookmark, copier / coller, et les effets viraux, en avec la transmission très facile de l’adresse du site) ;
  • L’utilisateur est (normalement) en sécurité, l’application en ligne ne peut pas accéder aux ressources locales de l’ordinateur : ni les fichiers sur le disque dur, ni les périphériques (micro, caméra, …). Rien excepté la zone graphique contenu dans la fenêtre du navigateur, la souris et le clavier pour entrer des données ;
  • L’interface est assez bien balisée (là aussi, normalement ;) ), et l’utilisateur a des repères, il sait ce que c’est qu’un formulaire, qu’un lien, une page, …
  • L’application est la même, quelque soit l’ordinateur, le système d’exploitation, le navigateur (ok, je simplifie ;) ).

Inconvénients :

  • Avec les applications évoluées, le navigateur est “décalé” : le bouton back est inutilisable, l’application a besoin d’accéder à plus de ressources (caméra, …) et l’interface est un peu limité ;
  • L’application n’est accessible que quand il y a une connexion Internet (a modérer, avec les propositions de Google).

C’est donc pour donner “plus d’air” aux applications en ligne qu’Adobe a développé son AIR.

L’idée est d’avoir le beurre et l’argent du beurre.

En fait, c’est évidement pas si simple :

  • L’utilisateur doit installer l’application AIR (ok, très peu de clics) ;
  • Les mises à jour sont pratiquement transparentes : comme il y a une application locale, il faut bien mettre à jour l’application. Mais cette mise à jour est automatisée (comme la plupart des applications, aujourd’hui) ;
  • L’interface n’est plus du tout banalisée. Ce n’est pas une critique, puisque justement c’est le but, de sortir des limites du navigateur. Le résultat sera dépendant de ce que feront les éditeurs… On verra le meilleur et le pire !
  • L’application est bien la même, quelque soit la plate-forme, c’est ce qu’apporte le moteur AIR.
  • L’application peut fonctionner en mode off-line, cela dépend de l’application (l’application eBay en mode off-line n’est pas opérationnelle) ;
  • On peut bien sûr se passer l’url qui pointe vers la page d’installation de l’application, mais il est certain qu’on n’aura pas le même niveau de viralité par rapport aux URL…
  • La sécurité : ah, je suis impatient d’en savoir plus demain. Adobe devait y travailler, c’est évidement un sujet clé.

Dans une application AIR, le runtime AIR n’est pas visible, seule l’application apparait sur le bureau de l’ordinateur.

La gestion des applications est donc laissée au gestionnaire de fichier de l’ordinateur.

C’est là que je reviens avec mon idée, d’un navigateur sans bord de fenêtre… C’est peut être un compromis plus intéressant : garder la notion de navigateur, d’URL, mais avec certaines applications en ligne, qui prendraient la main sur la fenêtre du navigateur.

Pourquoi ?

  • Pour garder justement la notion d’URL et tous les avantages associés ;
  • Pour avoir le double mode : service Internet ou service “application” ;
  • Pour simplifier encore plus les processus d’installation ;

Mais voilà, Adobe ne me demande pas mon avis pour spécifier ses produits. Microsoft non plus remarquez !

21.02

La troisième voie pour le logiciel

Publié dans , | 5 commentaires »

Au début, c’était simple.

Le logiciel est édité par des éditeurs, qui vendent leur logiciel le prix qu’ils veulent.

Microsoft, Oracle, SAP…

Tous ces acteurs se sont ainsi “goinfrés” avec des prix sans rapport avec les coûts de fabrication, et des abus de tous ordres, comme une maintenance soit disant évolutive, pratiquement obligatoire et cher (en général 20% du prix d’achat), qui n’a d’évolutive que le nom, car l’éditeur ne se gênait pas pour sortir une nouvelle version du logiciel, non couverte par la maintenance (obligé de tout repayer donc si on veut la dernière version)….

Ces abus ont ouvert la voie au logiciel libre.

Des “étudiants chevelus” se sont associés pour travailler ensemble sur des logiciels, qui marchent, qui sont gratuits, et qui sont livrés avec le code source, modifiable donc par les utilisateurs.

Je pense que ce modèle est très bien dans certains cas, mais ne peut pas être généralisé. A mon sens, c’est réducteur. Pourquoi une entreprise qui investi dans du logiciel ne pourrait elle pas en vivre, en vendant son logiciel ?

Je sais que cette discussion peut générer des passions, l’open-source, c’est parfois une religion ;)

Pourquoi l’entreprise qui a développé un logiciel devrait elle obligatoirement livrer son code source, alors qu’elle a éventuellement déployé de gros efforts pour avoir un système innovant, plus performant pour l’utilisateur.

Aujourd’hui, on navigue entre les deux modèles, la licence d’un côté et le libre de l’autre.

Je pense donc que les éditeurs de logiciels payent pour leurs “parents abusifs”.

Je pense qu’il existe une troisième voie. Je cherche un nom, j’appelle ça le “logiciel éthique” (un amis me disait que ça collait pas, parce que éthique fait référence à d’autres valeurs, …).

Bref, cette troisième voie, c’est une voie ou on fait du logiciel, pas open-source, pas gratuit, mais avec des garanties pour le client.

La principale garantie, c’est de tout mettre en œuvre pour que le client ne soit pas bloqué avec une solution unique, qu’il puisse changer de fournisseur si un fournisseur fait défaut, ou abuse de sa position.

Un logiciel, c’est un programme qui “discute” avec son entourage.

L’idée serait donc de définir très précisément les interfaces des logiciels.

Cette idée est parfaitement en phase avec ma conviction que l’avenir (ok moyen/long terme) du logiciel passe par le SAAS.

Des Composants SAAS discutent avec d’autres composants via des web services. Normaliser les échanges, c’est donc normaliser les services web des composants…

Les dernières news sur Microsoft me semblent aller dans ce sens là, mais on ne change pas de culture comme ça !

18.02

Nouvelle rechute ;)

Publié dans , , | 2 commentaires »

Comme vous le savez sans doute, je suis en pleine préparation de notre p’tit dej Rich commerce.

On a clairement choisi avec Fred une orientation plutôt “non technologique”.

J’ai pas pu m’empêcher, j’avais préparé tout un tas de slides sur l’architecture MVC adéquate pour décliner les interfaces riches…

En relisant notre présentation, on s’est rendu compte que c’était décallé !

Zut !

Alors je publie une image sur ce blog, et vous ne la verrez pas demain lors de la présentation !

Architecture MVC et interfacs riches

Compréhensible sans explication de texte ?

9.02

Organiser les développements : suite avec Laurent

Publié dans | Aucun commentaire »

Laurent a publié un commentaire, suite à mon billet sur l’organisation des développements.

J’ai pensé que ce commentaire “méritait” d’être “remonté” au niveau billet.

Voici donc les recommandations d’Ysance pour organiser les développements :

Lorsqu’on développe à plusieurs (ou même tout seul), les outils d’organisation de travail et groupe sont cruciaux, mais ne doivent pas nuire à la productivité ( combien de fois j’ai vu des plates-formes où il fallait plusieurs minutes pour mettre à jour un fichier, compiler, tester, tout ca parce qu’il était interdit de ‘travailler sur son PC’ !). Je vais me permettre de donner/compléter (succintement) quelques pistes :

  • La plate-forme de développement : principalement sur les postes de développeurs et un SVN, mais mutualisant généralement la base de données pour éviter les désagréments d’évolution des modèles. La base de données étant sous la responsabilité d’une (et d’une seule) personne. Chaque développeur produit des tests unitaires pour ses dévleoppements.
  • Une plate-forme d’intégration continue (de type CruiseControl ou autre) : Dès qu’une mise à jour de SVN est détectée, update de la branche, recompilation, déploiement scripté de la totalité du projet, et lancement des tests unitaires. Ainsi, pas besoin d’attendre plusieurs jours avant de détecter des problèmes d’intégration. C’est un peu long à mettre en place, mais ces techniques ont largement prouvé leur efficacité sur le moyen/long terme.
  • Une plate-forme de recette : Elle sert à valider fonctionnellement les développements. Celle-ci peut aussi être déployée à l’aide des scripts d’intégration continue pour faciliter. Je demande à mes équipes de mettre en ligne généralement deux ou trois fois par semaine. Cela permet aussi de suivre l’avancement général des développements et de ne pas être surpris la veille de la livraison :-)
  • Une plate-forme de pré-production : A l’identique “techniquement” (mais en version réduite pour limiter les coûts) de la plate-forme de production. L’objectif ici est de mettre en situation réelle (chez l’hébergeur, avec firewalls, DNS…) l’application avant déploiement pour réaliser une recette technique.
  • Une plate-forme de production : Pour limite la casse, dupliquer la production sur la pré-production avant recette technique. Préparer des scripts de retour en arrière (ca c’est la théorie, mais le jour où on en a besoin, on est bien content d’en disposer). Et enfin… faire les installation en production de préférence le lundi ou le mardi, jamais le vendredi (c’est toujours bon de le rappeler) !

Ca fait beaucoup d’environnements, certes, mais si la plate-forme est bien paramétrables (URL, DNS, adresses IP de chaque service) dans des fichiers de configuration, quasimment un seul fichier (web.config, config.php, autre…) peut permettre de paramétrer l’ensemble de la plate-forme.

Tout cela ne sont que des principes d’organisation et doivent être bien entendu couplés à l’organisation de l’équipe et les méthodes de développement (développement itératif, scrum, …)

Laurent

6.02

Rechute…

Publié dans , | 2 commentaires »

Demain, je retourne à “mes premiers amours” : PROGRAMMER !

Je vais à une formation Flex, organisée par Baao et sponsorisé par Adobe.

J’ai commencé ma vie professionnelle en développant des applications… en programmant quoi.

Je dois vous avouer : même si j’adore mon métier (à la frontière du marketing et de la technique), j’éprouve un grand plaisir à reprendre la programmation.

Pour tout dire, je me sens comme un gamin, qui “fait des légos en cachette alors qu’il a pleins de devoirs”. Vous voyez ce que je veux dire ?

Légo !

4.02

Organiser les développements

Publié dans | 12 commentaires »

Quand on développe un site marchand, il est très important de bien organiser les développements.

En particulier, il faut très rapidement aller vers plusieurs plate-formes informatiques :

La plate-forme de développement

C’est sur cette plate-forme que les développeurs… développent.

Après avoir testé le bout de service qu’ils développent en local, sur leur machine, ils peuvent migrer le nouveau programme sur la plate-forme de développement et faire des tests, avec les programmes des autres.

La plate-forme de production

C’est la plate-forme en ligne, celle qui est visible par les clients, les Internautes.

La plate-forme de pré-production

C’est un sas, entre le développement et la production.

Cette plate-forme est tout à fait fondamentale, car elle permet de garantir que les nouveaux développements n’impliquent pas de régression.

Quand l’équipe estime que la version courante de développement est stable, on fait une migration, vers la pré-production, pour tout tester, dans tous les sens. Si les tests passent, on peut alors migrer, de la plate-forme de “pré-prod” vers la prod.

Simple, non ?

« Articles plus anciens
Articles plus récents »