Archives de catégorie : Software

un peu de juridique: les clauses pénales dans les contrats BtoB

Lassé de négociations (sans fin) sur les clauses pénales introduites dans les contrats que je rédige pour mes clients, je me décide, en ce jour de grâce du 17 mars 2014, de repartir sur les bancs de la Faculté et de faire un point sur la doctrine (JurisClasseur notamment) et la jurisprudence en la matière. Les explications qui suivent s’appliquent à tout type de contrat BtoB (pas seulement les contrats de service logiciel en mode « SaaS »). Ce type de clause est un « classique » des contrat avec garanties de niveau de service (les fameux « SLA »).

1 – La clause litigieuse

« En cas d’indisponibilité du Service ou de l’hébergement (hors fonctionnement de l’Internet et opération de maintenance programmée du Logiciel et de la plate-forme d’hébergement), pendant un délai plus long que celui visé à l’article xxx, le PRESTATAIRE est réputée manquer à ses engagements qualité, ce qui entraine l’application de pénalités forfaitaires. Les parties conviennent que les pénalités notifiées par le CLIENT au PRESTATAIRE et non- contestées par écrit par le PRESTATAIRE pourront être recouvrées par compensation avec le montant des sommes dues par le CLIENT au titre du Contrat. Les pénalités ne sauraient excéder par année civile d’exécution du Contrat cinq (5) % des sommes payées par le CLIENT pendant la même période. En cas d’atteinte du plafond des pénalités, chaque partie disposera du droit de résilier le Contrat. »

2 – Ce que dit la loi

2.1 – article 1152 Code civil

« Lorsque la convention porte que celui qui manquera de l’exécuter payera une certaine somme à titre de dommages-intérêts, il ne peut être alloué à l’autre partie une somme plus forte, ni moindre.

Néanmoins, le juge peut, même d’office, modérer ou augmenter la peine qui avait été convenue, si elle est manifestement excessive ou dérisoire. Toute stipulation contraire sera réputée non écrite. »

2.2 – articles 1226 Code civil

« La clause pénale est celle par laquelle une personne, pour assurer l’exécution d’une convention, s’engage à quelque chose en cas d’inexécution. »

2.3 – article 1229 Code civil (le plus méconnu – hélas)

« La clause pénale est la compensation des dommages et intérêts que le créancier souffre de l’inexécution de l’obligation principale.

Il ne peut demander en même temps le principal et la peine, à moins qu’elle n’ait été stipulée pour le simple retard. »

Les plus courageux iront lire les articles de référence et rechercher confirmation de ce qui suit dans leur documentation juridique (d’une lecture toujours palpitante)… Pour les autres, voici une brève synthèse de ce qu’il faut en retenir, sans trop abuser des termes « métier » propres aux juristes.

3 – A retenir

3.1 – La sanction…

Est une clause pénale tout clause d’un contrat qui prévoit, à titre de sanction,  l’indemnisation forfaitaire d’un  dommage causé par l’inexécution d’un contrat par une des parties. Quel que soit le titre ou le contenu de la clause (pouvoir souverain d’appréciation des juges).

3.2 – … d’une inexécution…

Il faut donc une inexécution (un « manquement » ou une « non exécution totale ou partielle » – pas besoin de « faute » en matière de responsabilité contractuelle) du contrat pour appliquer une clause pénale. Cette inexécution peut être le non-respect d’une obligation de fourniture chiffrée qualitativement ou quantitativement (niveau de service ou SLA, etc. – voir par exemple « La clause litigieuse » ci-dessus).

3.3 – … forfaitaire…

La somme prévue dans la clause pénale représente des dommages-intérêts fixés forfaitairement, quelle que soit l’importance du dommage. Tant mieux pour son bénéficiaire si son préjudice est moindre que celui du montant fixé dans la clause pénale. Tant pis dans les autres cas… Ici, la liberté contractuelle prévaut. Et le contrat fait la « loi des parties » (article 1134 Code civil).

3.4 – … révisable seulement par le juge

Seul un juge peut accorder une somme moindre ou plus forte lorsque la clause est « manifestement excessive ou dérisoire » (article 1152 Code civil). Et toute clause contractuelle destinée à l’en empêcher est nulle.

4 – Les exceptions (qui n’en sont pas !)

4.1 – Les intérêts de retard

Les « pénalités » mises à la charge d’un l’acheteur en cas de retard de paiement ne constituent pas une clause pénale. C’est le principe même visé à l’article 1229 Code civil (alinéa 2).

Pour cette raison, les dispositions de l’article L.441-6 du Code de commerce (qui encadre les intérêts de retard entre commerçants) ne peuvent être modulées à la hausse ou à la baisse par un juge. Et si le retard a causé un préjudice, celui qui a souffert du retard peut en réclamer librement l’indemnisation, en plus d’empocher les intérêts de retard prévus (ou non) au contrat. Car les intérêts de reatrd sont payable « de droit » nous apprend le Code de commerce (mais si aucune clause du contrat ne le rappelle).

4.2 – Les clauses de dédit

De la même manière, les clauses qui prévoient le versement d’une somme si une des parties fait un choix au titre du contrat, ne sont pas des clauses de pénalités.

L’exemple type est celui des clauses de « dédit » dans les promesses unilatérales de vente. Si une partie peut décider de verser 10.000 €uros en application d’une promesse de vente (qui n’est pas synallagmatique), la partie qui s’est engagée peut ne pas poursuivre la promesse, mais elle laissera les 10.000 €uros au bénéficiaire de la promesse.

Il n’y a donc pas inexécution de la part de celui qui a promis de payer, mais exercice d’un choix. Ce n’est donc pas une « pénalité ». C’est également en ce sens que tranche la jurisprudence actuelle pour les clauses prévoyant une « indemnité en cas de remboursement anticipé d’un prêt ». La clause pénale, elle, n’est pas l’expression d’un choix pour le débiteur. Seul le créancier (le bénéficiaire) de l’obligation peut décider (ou pas) d’en demander l’application.

5 – Conséquences

5.1 – Le montant prévu dans la clause et rien d’autre

Le bénéficiaire de la clause pénale (on l’appelle aussi le « créancier de l’obligation ») ne peut pas demander en plus l’indemnisation du préjudice causé par ce même dommage. C’est le principe même imposé par l’article 1229 Code civil.

Le bénéficiaire de la clause peut en revanche librement demander l’indemnisation de tout autre dommage, distinct, même s’il est causé par la même inexécution au titre du même contrat.

Bon courage pour apporter cette preuve…

5.2 – Pas de dérogation contractuelle

Le régime prévu par le code civil (en 1804) est d’ordre public. Ce qui signifie que les parties ne peuvent y déroger contractuellement, sauf pour les exceptions prévues par ces mêmes textes, ce qui est le cas de l’inexécution par retard (hypothèse du respect d’un calendrier d’exécution contractuelle assortie d’une pénalité qui est prévue à l’article 1229 alinéa 2 Code civil).

Les clauses stipulant que « la clause pénale n’est pas libératoire et n’empêche pas le [bénéficiaire de la clause] de solliciter l’indemnisation de son entier préjudice » est donc nulle.

Voilà. C’est dit !

6 – La clause d’astreinte: une solution ?

Hélas, les plus imaginatifs (ou tordus) des juristes  pourraient être tentés de remplacer le mot « pénalité » par les mot « astreinte » dans leur clause habituelle. Mais nos amis les juges (car les juges sont nos amis) ont bien prévu le piège et la jurisprudence est là pour nous le rappeler :

« Les clauses dites d’astreinte, dès l’instant qu’elles stipulent une pénalité en cas d’inexécution d’une obligation, ne sont que des clauses pénales » (voir à titre d’exemple Cour d’Appel de Paris 2ème ch. A 11 janvier 1994 ou Cour d’Appel d’Aix-en-Provence 1ère  ch. 27 mai 1992).

7 – A noter si vous transigez…

Lorsque les parties mettent un terme amiable à un litige judiciaire, né ou à naitre, elles peuvent convenir de « transiger » le différend par la signature d’un protocole d’accord. La transaction est un contrat qui a valeur de jugement de première instance, et met un terme définitif à un litige judiciaire, né ou à naitre. C’est donc avant tout un contrat. A ce titre, il est parfaitement possible de prévoir dans le protocole une « pénalité » en cas de non-exécution par l’une ou l’autre des parties de ses obligation au titre du protocole lui-même.

Nous renvoyons les amateurs du pur « style 1804 » à la lecture de l’article 2047 Code civil :

« On peut ajouter à une transaction la stipulation d’une peine contre celui qui manquera de l’exécuter ».

Dura Lex (mais) sed Lex !

Marc-Antoine Ledieu – Avocat à la Cour

contact@ledieu-avocats.fr

Quel environnement technique pour un site e-commerce ?

Quand on se lance dans un projet e-commerce, on peut se retrouver dans la situation ou l’on doit choisir un langage de programmation, et plus largement, un environnement technique (OS, serveur, langage, base).

La question est importante, parce qu’elle a beaucoup de conséquences, sur les équipes, l’architecture, et les composants, qu’on pourra plus ou moins facilement ajouter.

Quels sont les grands éléments de cet environnement ?

  • Langage de programmation
  • Serveur
  • Base de données
  • Environnement de programmation
  • Système d’exploitation

On peut commencer par parler des langages de programmation.

D’abord, il faut dire que tous les langages ont une couverture fonctionnelle identique : il n’y a pas de langage qui permet de faire quelque chose, qu’on ne peut pas faire avec un autre langage.

Comment choisir alors ?

Voici quelques critères :

  • Compétences des équipes : Si les équipes maîtrisent un langage (Java par exemple), cela prendra du temps de les former à un nouveau langage. Ce n’est pas forcément rédhibitoire, surtout si on a du temps, mais, existe-t-il des projets ou on a du temps 😉 ?
  • Budget : Certains langages sont gratuits (Java, PHP, Ruby On Rails), et certains sont payants (.NET).
  • Délais. Certains langages, associés à des librairies, permettent de gagner du temps, de développer les services plus vite.
  • Environnement existant : Vous avez déjà tout un environnement, basé sur une technologie. C’est sans doute une bonne idée de faire un développement cohérent par rapport à cet existant.
  • Contour fonctionnel : avec le langage on choisi « de facto » les librairies sur lesquelles on pourra s’appuyer. Si par exemple on doit intégrer un module de CRM, PHP permet de faire ça assez facilement, avec des modules comme SugarCRM.
  • Robustesse de l’application : il est beaucoup plus facile de faire du code robuste en Java ou .NET qu’en PHP. PHP, pour rester sur cet exemple, est tolérant par rapport aux erreurs. La concéquence est qu’il est beaucoup plus difficile d’écrire une application 100% bug free en PHP qu’en Java. Bon, ce point doit être modéré, parce que la qualité finale dépend de tout un tas de facteurs : librairies utilisées, compétences des équipes, …

Je ne mets pas la performance comme critère, parce qu’on peut faire des services performants avec tous les langages (on peut également faire des systèmes qui rament avec tous les langages, c’est même assez facile 😉 ). A chaque fois, il convient « simplement » d’ajuster l’architecture.

Bon, vous me direz peut être que tout ça ne vous guide pas vraiment !

Prenons les trois langages les plus utilisés aujourd’hui : PHP, Java et C#.

PHP

Avantages

  • Gratuit ;
  • Très bien intégré dans la couche LAMP (Linux / Apache / MySQL / PHP) ;
  • Grosse communauté d’utilisateurs, et donc beaucoup de librairies disponibles ;
  • On trouve (relativement) facilement des ressources, soit pour recruter, soit en prestation ;

Inconvénients

  • Trop tolérant aux erreurs (pas de typage, …), et donc cela augmente « mécaniquement » le risque d’avoir un service buggé ;
  • Environnement de développement assez pauvre (pas de débugger encore bien stable).

Java

Avantages

  • Gratuit, mais attention, il faut ajouter un serveur d’application qui n’est pas forcément gratuit. Le serveur d’application est une couche, qui s’intercale entre Apache (le serveur Web) et le langage Java.
  • Très bon environnement de développement, gratuit (Eclipse) ;
  • Grosse communauté, on trouve beaucoup de composants libres ou pas sur le marché ;
  • Langage de très bonne qualité, qui permet, plus facilement qu’en PHP, de faire des programmes robustes et fiables.

Inconvénients

  • On trouve un peu moins de ressources qu’en PHP.
  • Les développements sont souvent un peu plus long qu’avec PHP. C’est la concéquence, le prix à payer ;
  • Comme il y a moins de développeurs Java que PHP, les prix sont un peu plus élevés. La facture est donc un peu plus lourde qu’avec du PHP.

C#

Avantages

  • Au niveau qualité du langage, on est au même niveau qu’avec le Java, mais l’intégration entre le langage et l’environnement de développement (Visual Studio) est plus forte. Au final, le développeur a entre les mains un outils de développement de très grande qualité ;
  • On bénéficie du support d’un grand éditeur ;
  • On peut gagner plus de temps, par rapport au Java, grâce aux nombreuses librairies fournies par Microsoft.

Inconvénients

  • Solution la plus chère, à tous les niveaux : licences, ressources.
  • Ce choix est très structurant, et le choix Microsoft a tendance à « se répandre » : on prend .NET, puis SqlServer, puis IIS, puis Windows Server, puis… On fini rapidement par avoir l’ensemble des logiciels Microsoft, et on revient sur le premier point : attention à la facture !

Au final

Pas simple, pas de réponse universelle.

Autre point important : un projet a une durée de vie limitée, une période d’amortissement. Un site qui vit 3 à 5 ans, c’est bien. Aller au delà n’est pas forcément très raisonnable.

encore un autre point : le choix n’est pas forcément unique : on peut faire le front en PHP, le back en Java, … Avec les Web Services, les différents langages savent dialoguer. Mais : c’est des développements complémentaires et il faut dans ce cas avoir les deux compétences.

N’hésitez pas à commenter ce billet : j’ai essayé d’être synthétique, mais j’ai sans doute oublié des points !

Quel pricing pour les offres SAAS ?

Le SAAS est l’avenir de nos systèmes informatiques, en particulier pour le e-commerce.

Pour que cette mutation se fasse, il faut que les offres matures voient le jour, avec des prix adaptés.

Le modèle Salesforce

La star du SAAS, c’est Salesforce.com (solution qui permet de gérer les données liées à la prospection commerciale et au suivi de la relation avec les clients).

Le prix est principalement basé sur le nombre d’utilisateurs. Le prix d’appel est de 20$ par utilisateur et par mois.

Le modèle de prix est excellent : pour une petite boite, avec par exemple 2 ou 3 comptes, le prix est très bas.

Et puis, les revenus d’une boite sont toujours liés aux nombres de commerciaux. Le prix de la solution s’adapte donc très bien aux petites boites et aux gros groupes.

A l’autre bout de la chaîne, l’exemple d’Amazon

Amazon propose également des solutions SAAS, mais en « partant du bas ».

Amazon propose, avec S3, une solution de stockage et d’hébergement de services en lignes.

Voici la grille de prix proposé par Amazon :

Storage
$0.18 per GB-Month of storage used

Data Transfer
$0.10 per GB – all data transfer in

$0.18 per GB – first 10 TB / month data transfer out
$0.16 per GB – next 40 TB / month data transfer out
$0.13 per GB – data transfer out / month over 50 TB

Requests
$0.012 per 1,000 PUT or LIST requests
$0.012 per 10,000 GET and all other requests*

Comme vous pouvez le voir, le prix est 100% basé sur l’usage. On paye le stockage et les flux, entrants et sortants.

L’avantage de ce modèle est qu’il est lié aux coûts d’Amazon (qui doit acheter des disques pour stocker les données, et acheter de la bande passante).

Ce modèle présente à mon avis deux inconvénients :

  • Il n’est pas forcément évident, pour l’utilisateur, d’anticiper le prix de la solution ;
  • Le prix n’est pas dépendant des revenus. Cette solution sera très avantageuse pour certains, et très cher pour d’autres.

Les exemples liés au e-commerce

Plusieurs éditeurs de logiciels proposent dès aujourd’hui des solutions de type SAAS. Je pense en particulier à des solutions de moteur de recherche, à intégrer dans les sites marchands.

A mon sens, les solutions ne sont pas très matures (en tout cas au niveau du « packaging », de l’offre. Un signe qui ne trompe pas : impossible d’avoir une grille de prix. On est en fait sur du « sur mesure ».

Autre point : ces solutions visent plutôt les gros acteurs. On comprend la logique : il vaut mieux vendre une solution chère à un petit nombre d’acteurs que diluer son effort commercial, avec des petits revenus pour chaque vente.

C’est vrai, mais :

  • La concurrence est très rude : tout le monde cible les « gros poissons » ;
  • Le principe même du SAAS, c’est qu’on peut cibler tout le monde, y compris les petits acteurs, et qu’on y gagne de l’argent, avec un modèle du type ‘les petits ruisseaux font les gros fleuves ».

Autre élément : ces solutions sont aujourd’hui assez « technique » à mettre en œuvre. On est loin du « plug & play ».

Quel avenir ?

Les solutions doivent donc s’améliorer, avec une mise en œuvre plus rapide, et donc une interface plus simple, mieux travaillée (marrant, ça fait référence, sans que ce soit prémédité, à mon billet précédent).

On doit trouver un prix acceptable pour les petites boites et dans le même temps un prix qui rapporte suffisamment pour permettre à l’éditeur de vivre, en faisant évoluer la solution (investissement R&D).

Prenons l’exemple d’un moteur de gestion de catalogue, en SAAS donc.

Quels peuvent être les éléments de pricing :

  • Eléments « physiques » :
    • Nombre de produits ;
    • Espace physique occupé (un peu comme S3) ;
    • Nombre de visites ;
  • Autres critères :
    • Nombre de produits vendues par mois ;
    • Chiffre d’affaires ;

Le chiffre d’affaire est un critère qui peut sembler intéressant pour l’éditeur, mais il est délicat à faire accepter par les clients en général et par le e-commerçant en particulier.

Les critères physiques ont l’avantage de l’objectivité, mais cela ne me semble pas parfait non plus : un commerçant peut démarrer avec beaucoup de produits, sans pour autant avoir des revenus importants… Un peu comme si Salesforce.com nous faisait payer au nombre de contacts.

Vous le voyez, il reste du travail…

Autres articles sur le sujet :

L’art de l’abstraction

bien programmer est un art, où tout au moins un artisanat, un peu comme un ébéniste.

Par programmation, j’entends l’ensemble des activités, permettant de passer de l’expression d’un besoin à un système informatique. Cela regroupe donc ce qu’on appelle l’analyse, la conception, la programmation, les tests, …

Bien sûr, les grosses boites vous parlent de processus industriels.
Ils ne vont pas vous dire le contraire, quand on allonge une facture de plusieurs centaines de milliers d’euros…
Ce sont les mêmes qui réalisent les systèmes informatiques des grosses banques… Vous me suivez ?

Mais la réalité est aujourd’hui plus simple, toute nue : la qualité de votre système informatique, quel qu’il soit, dépend de la qualité des artisans qui le construisent.

Une des qualités fondamentale pour bien programmer, c’est l’art de l’abstraction.

Pourquoi ? (j’aurais pas du regarder Sarkozy l’autre soir moi, j’ai une rechute)

Quand on doit réaliser une application, la base de la programmation, c’est de découper le problème, dans deux sens : verticalement et horizontalement.

Verticalement : on sépare le problème, fonction par fonction (pour un front office, on parlera par exemple du processus achat, du catalogue produit…)

Horizontalement : on sépare le problème en couche (toujours pour notre front, on pourra faire une couche pour les données, une couche pour les objets métiers et enfin une couche présentation).

Ce découpage à pour but de définir des modules, entité informatique ayant d’une part une complexité maîtrisable et d’autre part une certaine homogénéité.

Pourquoi ?

  1. Un module doit être plus simple à programmer parce que le problème qu’on cherche à régler est une partie du problème global.
  2. Le module est plus homogène parce qu’il ne résoud qu’un type de problème (les données pour le processus achat par exemple).

Le programmeur, notre artisan, doit donc être capable de faire abstraction des autres problèmes (voisins de gauche et de droite et du dessous) pour se concentrer sur son « morceau » du problème.

ça encore, c’est pas le plus dur.

Le plus dur, c’est qu’il doit à son tour donner une interface à son module ayant le bon niveau d’abstraction.

Il doit bien faire la différence entre « sa cuisine interne » et la vue qu’il donne sur son module.

Concevoir l’interface d’un module est réellement une partie passionnante. On se retrouve dans la situation de définir le « panneau de contrôle », donnant donc une vision la plus simple et la plus abstraite du problème qu’on doit résoudre.

Les couches logicielles

Couches, du hard vers l'applicatif

Donc, à la base, il y a du matériel.

Pour donner vie à ce matériel, on rajoute un système d’exploitation.

Par dessus ce système, on ajoute des applications.

Une application bien particulière est le navigateur Internet.

Ensuite, nos services Internet peuvent prendre vie, soit directement dans le navigateur, soit via une extension, Flash ou Java.

Chaque flèche indique un endroit pour développer une application.

Live from OnAir

Je m’étais inscrit à la journée OnAir de Paris.Le monde est tout petit, c’est l’occasion de croiser Fred, Olivier Ezratty, Christophe Lauer

La présentation était réalisée par toute l’équipe d’évangélistes Adobe : Mike Chambers, Rayan Stewart, …

AIR, c’est la solution d’Adobe, pour « sortir du navigateur » et avoir des applications qui tournent directement sur le bureau de nos ordinateurs, avec une vrai logique multi-cible (PC, Mac, Linux).

Bon, faut le dire, cette journée est « terriblement » technique !

J’en parlais avec Christophe Lauer, évangéliste microsoft sur les technos Sylverlight, c’est marrant comment Microsoft qui a un background technique fait tout pour draguer les designer, en faisant des présentations ou la programmation est plutôt caché, alors qu’Adobe, qui vient plus du monde des designers, fait des présentations super techniques (on a vu des lignes de commandes 😉 ).

Autre point vraiment intéressant : les logos des premiers utilisateurs : Salesforce.com, SAP, …

Comme évoqué dans ce billet sur RichCommerce, la logique AIR prend tout son sens pour certains éditeurs, c’est un retour de balancier après une période « full web ».

L’approche AIR est une vrai alternative, pour développer plutôt simplement une application ayant une interface nickel, qui tournera sur toutes les machines, et qui sera assez simple à déployer.

A ce titre, Adobe joue relativement seul sur ce terrain : Java n’est pas aussi simple et Microsoft n’a pas d’alternative (WPF n’est pas multi-OS et Sylverlight ne sort pas du navigateur).

CRM / SugarCRM – Partie 2

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.

CRM / SugarCRM – Partie 1

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 !

Avancer vite, ou sécuriser ?

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 !

Abstraction or not abstraction

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 !