Archives par mot-clé : Système d’information

un nouveau langage pour Internet ?

On réalise des sites dynamiques en programmant… Avec un langage de programmation donc.

Si, théoriquement, on peut faire des services internet avec n’importe quel langage, en réalité, il existe pas tant que ça de solutions :

  • C# dans .Net : proposé par Microsoft, c’est un très bon langage, avec un environnement de développement pil poil. C’est du propre : compilé, typé… Le problème est que quand on met un doigt là dedans, on en sort « full microsoft » avant d’avoir compris ce qui se passait… Et la facture licence peut faire peur…
  • Java : Solution normalement aussi propre que C#, avec l’avantage d’avoir des outils gratuits… Bon, la réalité est que, bien souvent, les architectures Java sont un peu lourdes, un peu verbeuses… On a rapidement des « délires UML » cher à développer et à maintenir.
  • PHP : LA solution Web par excellence. Langage simple à prendre en main, bien adapté à la production de pages dynamiques. Tout est fait pour faciliter l’écriture de petits programmes… Mais le contexte à bien changé depuis les débuts du langages. Ce langage est en fait utilisé par un nombre incroyablement grand de sites web (30 % ?), et PHP motorise donc des petits sites, mais également quelques monstres (comme Flickr !). Le fait que la plupart des hébergeurs proposent des solutions PHP clés en main accélère la diffusion de ce langage.
  • Autres langages interprétés (Python, Perl, Ruby…) : il existe pas mal d’autres langages, orientés Web. Ruby est par exemple une solution assez puissante pour produire des sites avec peu de ligne de code (ce qui est un critère de qualité : moins de ligne, mois de bug 😉 ).
  • C et C++ : Ce sont des langages bien solides, qui permettent de faire des applications excessivement rapides… Mais finalement, aujourd’hui, peu de monde utilise ces langages pour développer des sites web… Bon, quand même : les éléments clés des algos de Google sont développés en C…

Le PHP joue donc un rôle clé dans le développement du Web aujourd’hui.

Sa flexibilité, la taille de la communauté, la gratuite, … Beaucoup de facteurs ont poussé son développement, et aujourd’hui, la communauté PHP est juste phénoménale.

Mais aujourd’hui, je trouve la situation un peu paradoxale :

Qu’un site qui se lance parte sur PHP, je comprends : coût de développement réduit, pas de frais de licences, …

Mais ces contraintes changent complètement quand un site est plus important. Pour un gros site, la qualité devient un élément fondamental. Il faut donc être certain que le programme va bien produire le résultat attendu. Et pour ça, rien ne vaut un langage compilé, avec un typage stricte.

La solution actuelle consiste à rajouter des couches sur PHP, avec Zend Framework, …

Mais je pense, surtout après ma discussion avec Zeev, que l’avenir passera à moyen terme par l’émergence d’un nouveau langage.

Le cahier des charges est, à mon avis :

  • Langage compilé et typé ;
  • Langage orienté Web : disposer de syntaxes très simple pour produire des pages HTML ;
  • Peut être intégrer dans le langage une solution native pour gérer les sessions (et arrêter de charger la base de données avec des infos qui n’ont rien à y faire) ;
  • Langage objet bien sûr, pour faire de beaux modèles 😉 ;
  • Langage open source et gratuit, parce que c’est la clé de la diffusion sur Internet, et, comme PHP, parfaitement intégré à Apache.

La barrière à l’entrée est assez élevé, parce qu’il y a pas mal de choses sur le marché…

NB : ce billet est un billet de « projection ». A court terme, on peut très bien développer de bons services avec les outils actuels. On remplace les insuffisances de tels ou tels langage par de la méthode et des outils !

CMS et moteur e-commerce

En voilà un sujet !

Bon, de quoi parle-t-on ?

Moteur e-commerce : C’est une solution parfaite (normalement) pour gérer un catalogue, des produits, un processus achat, …

CMS : Solution (normalement) parfaitement adapté pour mettre en ligne du contenu : des pages conseil, des guides, …

Beaucoup de sites e-commerces auraient besoin des deux :

  • Un moteur e-commerce pour la partie marchande ;
  • Un moteur CMS pour toutes les pages de contenu.

On peut faire ça en mettant cote à cote deux moteurs… Mais le résultat sera lourd et décevant :

  • Les deux systèmes doivent avoir la même interface. Deux systèmes séparé demanderont une double gestion des interfaces.
  • Les deux systèmes ne doivent pas être indépendant. Exemples : on doit pouvoir importer le panier, le compte client dans le CMS, et on doit pouvoir importer des contenus du CMS dans les pages e-commerce.

Alors ?

La solution est de travailler à une intégration plus fine…

A suivre donc, ce billet est (aussi) un « teasing » pour un ami !

Le prix d’une boutique en ligne

On me demande souvent le prix à payer pour une solution e-commerce.

Et c’est une question difficile

Comment répondre, quand on peut effectivement payer entre zero et plusieurs millions d’euros ?

Bon, essayons de mettre ça a plat.

D’abord, quand on parle de solution e-commerce, on peut en fait parler de différentes choses :

  • Juste un site, avec son back office d’administration ;
  • Un site qui doit s’intégrer avec d’autres pages de contenu. On a donc un site e-commerce, plus des pages de type « CMS », et le tout doit être parfaitement cohérent ;
  • Un site, qui doit supporter un très grand nombre de visiteurs simultanés, tout en gardant des temps de réponses très courts ;
  • Un site qui doit impérativement rester en ligne tout le temps ;
  • Un site, qui doit être branché sur le reste du système d’information de l’entreprise : comptabilité, gestion des stocks, logistique …
  • Un site, qui doit en fait se décliner en plusieurs sites, pour plusieurs pays ;
  • Un site, qui doit supporter des scénarios multi-canal : achat en ligne, retrait en magasin, …
  • Un site avec des outils bien adaptés à l’organisation de l’entreprise, avec en particulier le support de « workflow » (processus) : machin fait une modification, bidule la valide, …
  • Un site avec des processus de mise à jour un peu solides : les mises à jours sont effectuées sur un serveur de validation, puis quand les modifications sont bien validées, les données sont mises à jour sur le site de production ;
  • Un site robuste, qui supporte une large gamme de panne ;
  • Un site qui intègre une large gamme de médias ;
  • Un site évolutif, sur lequel qu’il doit être possible de faire évoluer à coût maîtrisés ;

Alors bien sûr, si votre besoin, c’est « la totale », que vous avez des centaines de milliers de visiteurs par jour, votre niveau d’investissement sera sans commune mesure avec un site de lancement, sans visiteur et sans branchement complexe vers le reste du système d’information.

Autre point à bien intégrer : on paye plusieurs choses :

  • La conception du système e-commerce (architecture du système d’information) ;
  • La conception du site e-commerce ;
  • La réalisation du site e-commerce
  • Le branchement sur les autres briques de l’entreprise ;
  • Les tests et la documentation ;
  • La réalisation de la conception graphique ;
  • Les licences logicielles ;
  • L’hébergement, avec l’investissement dans les serveurs, et les coûts de maintenances ;
  • La mise en oeuvre des outils de monitoring, pour bien suivre l’activité du site, et alerter en temps réel quand un problème est détecté ;

Pas de panique : vous démarrez, vous n’avez pas à payer tout ça : le système e-commerce est réduit à un simple serveur, pas de branchement, … Vous demandez à votre cousin de faire la charte graphique…

Et puis, on n’a pas nécessairement besoins de tout faire d’un coup.

Mais bon, pour les sites un peu important, on se retrouve à payer pas mal de choses, et on arrive comme ça tranquillement sur des solutions qui coûtes assez cher dans l’absolu.

Mais tout ça, c’est une question de point de vue…

Je rappelle au passage qu’Amazon investi plus d’un miliard de $ dans sa R&D…

Donc, question de point de vue car, si le projet est bien mené, les choix bien fait, il s’agit d’investissements raisonnés, permettant de développer un canal de vente stratégique.

On peut, pour le coup, comparer avec le monde physique : combien cela coûte-il d’ouvrir un magasin « en dur » ?

Donc, le système e-commerce doit à mon sens être considéré comme un actif, qu’il convient de développer dans la durée.

Anniversaire Appolo 11 : ce qui a fait la différence avec l’URSS…

C’était il y a 40 ans !

Mais pourquoi les américains ont ils réussis, là ou les russes ont échoués ?

Les russes étaient très fort, au niveau des fusées, des lanceurs, ce qui est quand même pas mal pour aller sur la lune !

C’est ce qui leur a permis de prendre pas mal d’avance au début de la course pour la lune.

Et puis… et puis les choses se sont inversées.

Les russes ont envoyé des engins qui devaient se poser sur la lune… et qui sont passés à des milliers de km.

Donc, les russes avaient les meilleurs lanceurs…

Ce qu’on a découvert assez récemment – après effondrement du mur de berlin et l’ouverture des archives soviétiques – c’est à quel point la différence était très forte au niveau de l’électronique, et surtout de l’informatique !

Vous voyez à quoi je pense 😉 ?

Ou est le directeur technique ?

Pour pas mal d’entreprises, les systèmes informatiques représentent un élément stratégique :

  • Stratégie de l’information ;
  • Stratégie de la flexibilité, de l’adaptabilité (qui doit s’appuyer sur des systèmes d’informations adaptés) ;
  • Stratégie Internet et e-commerce enfin.

Pourtant, dans bien des groupes, il n’y a pas de directeur informatique.

Ou encore, le directeur informatique rapporte au directeur financier.

Fréquent ce cas là…

Mais pourquoi donc rattacher l’informatique à la finance ?

La raison est en général historique : on rattache à la finance les activités « support » : achat des bureaux et du matériel, …

L’informatique apparaissait comme une activité dans cette catégorie là…

Et puis le temps a passé, personne n’a remis en cause cette organisation, alors que l’informatique est devenu centrale, stratégique (ok, je me répète un peu…).

Faire évoluer cette organisation est important : il est à mon sens tout à fait fondamental de faire évoluer l’informatique du statut de « centre de coût » au statut de « centre d’investissement stratégique », avec des objectifs business clairs, ambitieux.

Allez, on y va ?

Séparer le back du front

La plupart des systèmes e-commerce regroupent, sur un même serveur, le Front office et le back office.

Bon, quand on se lance, il est complètement normal de tout mettre sur un seul serveur : on n’a pas l’argent pour se payer plusieurs machines. Et puis le trafic des premiers mois ne pose pas vraiment de problème…

Par la suite, c’est une autre histoire.

Le site e-commerce représente un chiffre d’affaire concéquent… Et la moindre interruption de service met en danger l’équilibre de « la petite entreprise e-commerce ».

Le Front office doit donc être en ligne 24h sur 24, 7 jours sur 7.

Pour garantir ce résultat, il faut isoler le Front au maximum.

C’est le meilleur moyen de garantir que le front est « centré » sur sa mission : répondre, dans un temps très court, aux requêtes des internautes.

Le back office n’entre pas dans cette mission… Il doit donc être découplé du Front.

Une première étape peut être de monter une architecture à trois niveaux :

  • Le Front office, composé d’un ou plusieurs serveurs Web
  • La base de données, hébergée sur son propre serveur
  • Le Back office, hébergé sur un autre serveur

C’est une bonne solution, qui a l’avantage de pouvoir être mise en oeuvre pratiquement sans modifier les solutions e-commerce du marché.

Avantages :
Les programmes back office ne pénalisent plus le Front.

Limites majeures :
Si une page du back sollicite beaucoup la base de données, les temps de réponses du front seront bien impactés par l’utilisation du back…
Autre limite : toute bêtise sur le back sera instantannément visible sur le Front.

Et puis, pour un site plus pro, on souhaite un découplage plus fort :
On veut, par exemple, mettre à jour le catalogue, et pouvoir « recetter » les modifications, avant qu’elles soient en ligne.

L’étape d’après consiste donc à avoir un ensemble front complet, composé de serveurs front, avec une base de données dédiée.

Le back office est complètement séparé, avec sa propre base de données.

Si on part d’une solution e-commerce toute faite, on peut arriver à ce résultat assez facilement…

Toute la question, sur un tel système, c’est : comment synchroniser les données entre les bases du Front et du Back.

Là, pas de solution magique : il va faloir développer une couche de synchronisation.

Et ça, ça sera l’occasion de pleins d’autres billets…

Mes données en sécurité

Demande simple : je veux que mes données soient en sécurité.

Mais où sont elles le plus en sécurité ?

  • Sur mon disque dur ?
  • Sur un système RAID ?
  • Si j’en fais une copie sur un DVD ?
  • Et si je mettais mes données sur un serveurs tiers ?

Mais au fait, c’est quoi la sécurité ?

  • C’est de ne pas perdre mes données ?
  • C’est qu’on puisse pas me les voler ?
  • C’est qu’elles soient intègres ?

Bon, question simple qui se décline pas mal en fait…

Bien évidement, le « comment » doit être guidé par le « quoi » : il faut d’abord savoir l’objectif que l’on poursuit avant de « foncer » sur une solution technique.

Beaucoup de subjectif, de psychologique aussi :

Mes données sont plus en sécurité chez moi, sur mon disque dur

Au final, un vrai sujet, avec pas mal d’alternatives !

Mon ami Antoine

Antoine Cahen, ça fait un bout de temps qu’on se connait maintenant.

Antoine a participé à de biens belles aventures, comme par exemple Alapage…

Aujourd’hui, Antoine lance son blog, et rejoint Jean Paul Smet (Mr ERP5) pour développer l’offre Tiolive.

Tiolive, pour faire simple, c’est un ERP open-source, en mode SAAS… Des mots sympathiques, non ?

Bonne route Antoine !

Vous reprendrez bien une petite tranche de système d’information ?

Le système d’information, c’est l’ensemble du système informatique, qui tourne dans une entreprise.

Pour une entreprise qui fait du e-commerce, c’est bien sûr un site e-commerce, avec son (ses ?) back offices.

Mais c’est également tous les autres systèmes, plus ou moins anciens, plus ou moins interconnectés : ERP, CRM, …

Toutes les entreprises ont une histoire, et le système d’information de l’entreprise est une trace de cette histoire, souvent non linéaire ;).

Alors voilà, le contexte évolue rapidement, les techno aussi, et l’entreprise doit faire face à de nouveaux défis.

Le système d’information devient un boulet, qui freine l’entreprise.

Il faut donc repenser le système.

Certains (surtout les éditeurs 😉 ) vous proposeront de tout changer…

Pour ma part, je pense qu’une telle opération est en général très risqué. Je préfère travailler sur un plan d’évolution « en tranche » du système d’information.

Après analyse fine du système, l’idée est d’identifier des blocs fonctionnels, et de procéder à des évolutions partielles, morceau après morceau.

Cela parait simple comme ça… ça ne l’est pas forcément !

Comme je l’ai déjà évoqué dans ce billet, les traits d’un schéma sont très important

Pour dire les choses différemment, un point clé va être le travail sur les échanges entre les modules.

Il s’agit bien de faire évoluer le système d’information vers un système plus performant.

Il faut donc repenser les échanges entre les modules du système.

Je dois dire que c’est un truc qu’on j’adore faire chez Araok!

Alors, il est comment votre système d’information ?

Risque et vitesse : jusqu’ou iriez vous ?

J’ai eu le plaisir de déjeuner, ce midi, avec un ami.

On partage pas mal de choses, technique, e-commerce…

On discutait de la distortion qu’il y a, entre le travail que peut faire une personne seule, de bon niveau, et un travail pro.

Une personne seule peut développer tout un système d’information.

Si la personne est compétente, le système peut être rapidement opérationnel, et avoir une couverture fonctionnelle tout à fait respectable.

Maintenant, entre une telle méthode et une méthode plus qualitative, il peut y avoir une différence de cout de 10, voir de 100 !

Comment le justifier, comment l’expliquer ?

Mon ami m’a proposer l’analogie suivante, que j’ai trouvé marquante :

Tu dois construire une voiture.

C’est sûr, si tu ne prends pas le temps de faire des crash tests, tu ne prévoies pas de frein à main, aucun système de sécurité… tu peux aller très très vite, et pour pas très cher.

Maintenant, irais tu rouler régulièrement avec une telle voiture ?

Je trouve l’analogie excellente parce qu’elle est proche de la réalité : faire du très rapide à moyen très léger, ça marche, et ça permet de lancer, par exemple, un nouveau site rapidement avec un investissement très limité.

Mais il faut savoir ce que l’on a : on a un système qui fonctionne certe, mais qui ne sera pas résistant aux erreurs, mal adapté aux évolutions…