Les règles pour éviter la fraude

Les sites de vente en ligne sont sujet à plusieurs types de fraudes.

Mais il existe des moyens d’identifier la plupart de ces fraudes.

Comment ?

voici les règles :

Et non, je partage à peu près tout sur ce blog, mais je ne donnerais pas ces règles 😉

Pourquoi ?

Pour une seule raison : je ne veux pas que ces règles soient publiques. Sinon, elles perdraient instantanément leur valeur, étant connues des fraudeurs.

Si vous avez un site, vous pouvez me contacter, ou contacter d’autres spécialistes.

Il existe également des sociétés spécialisées dans la détection des fraudes, comme Fia Net.

Patrice Cassard récidive et sort un nouveau site : neeed

Neeed est un tout nouveau site, imaginé par Patrice.

Donc Neeed : ce site propose à chacun de se créer des listes de produits, trouvés sur des boutiques en ligne.

L’enregistrement se fait via son compte Facebook ou Twitter.

Une fois enregistré, on ajoute un raccourci à son navigateur.

Ensuite, on va sur n’importe quel site, sur n’importe quel fiche produit. Un clic sur le raccourci permet d’afficher un cadre autour du produit à ajouter :

Un clic sur le bouton « Ajouter » permet de compléter les informations sur le produit :

Les informations à ajouter sont très simples : catégorie, et gamme de prix.

Ensuite, le produit est automatiquement ajouté à la liste de mes produits sur Neeed :

On constitue sa liste à partir de produits trouvés sur d’autres sites donc, mais également à partir des produits identifiés par d’autres membres de la communauté Neeed.

Il s’agit donc d’un réseau social, ou chacun a sa propre liste de produits préférés. On peut suivre d’autres membres et donc être suivi.

J’ai trouvé le site très très bien fait, le design vraiment super

Si vous testez, n’oubliez pas que le site est en « alpha » : tout n’est pas fini.

Je suis pour ma part convaincu qu’il y a de la valeur à créer des services de qualités, entre les consommateurs et les sites marchands, donc pil poil sur ce type de positionnement.

Des services de ce type existent aux US : SvpplyFancy ou Lyst.

A suivre : comment l’usage va se développer, et  quel sera le modèle économique le mieux adapté ?

(autres infos ici, merci à Olivier)

 

 

Les outils pour enrichir le CSS

Le CSS, c’est le langage qui permet de faire la mise en forme des pages web.

Cela permet de séparer le fond de la forme : le HTML contient le fond (le texte en particulier), et la décoration se fait via le CSS (la police, la taille, les bordures, …).

Bon, ça, c’est la théorie ;).

Dans la pratique, écrire une couche présentation en CSS est très technique, avec certaines parties plutôt répétitives et impossible à factoriser. Exemple : un site utilise une palette de couleurs. Impossible, en CSS, de définir des constantes avec ces codes couleurs.

Sinon, quand on n’arrive pas à faire ce qu’on veut en CSS, on le fait en Javascript.

Certains proposent d’améliorer tout ça avec des « méta langages » au dessus de CSS.

Exemples : SASS, LESS, …

SASS est une technologie côté serveur, on passe son code CSS enrichi dans la moulinette SASS et ça ressort un code CSS standard.

Si j’ai bien compris, LESS permet à peu près la même chose, avec une technologie Javascript, qui peut être côté client ou serveur.

Je ne rentrerais pas dans le détail, ce n’est pas l’objet de ce blog.

Je trouve que c’est une super bonne idée, que de proposer des langages, ou méta langages, qui permettent de programmer plus propre, plus court.

Mais cela ouvre la voie suivante :

Le code que j’écris n’est pas le code envoyé côté client.

Avantage : le code que j’écris est plus court, de meilleure qualité.

Inconvenient : ce que je vais débuggé n’est pas ce que j’ai écrit.

Mon avis, très clairement, est que c’est bien l’avenir !

Je pense depuis longtemps qu’à moyen terme, les langages du web n’ont pas vocation à être manipulés directement : ce sont, de mon point de vue, des langages de trop bas niveaux, avec des contraintes beaucoup trop complexes. Je pense bien sûr en particulier au problème de multi-terminal / multi navigateur.

Pour prendre une analogie, cela me fait penser au Postscript : c’est un langage de bas niveau pour piloter les imprimantes (ou autres interfaces d’ailleurs). Mais personne n’aurait l’idée d’écrire à la main du code Postscript !

J’ai donc la conviction qu’il devrait sortir des systèmes qui vont bien plus loin dans cette voie :

C’est une voie étroite, parce que, de mon point de vue, ces systèmes doivent être spécifiques web, alors que ce qu’on voit bien souvent, ce sont des frameworks génériques, et je ne crois pas du tout à cette approche.

C’est pour cela que je trouve les initiatives type LESS ou SASS particulièrement intéressantes : on améliore la qualité, de manière très spécifique au Web.

Et vous, qu’en pensez vous ?

Quand l’image sort du cadre

On le dit, on le répète : pour un site e-commerce, la qualité des photos est un élément clé.

Maintenant, quand on a de belles photos, il faut les mettre en avant !

Certains sites proposent des photos de plus en plus grandes.

Le site KillSpencer, trouvé au hasard de surfs, va très loin.

Page d’accueil  :

Un peu dans l’esprit de ce que fait Apple, la home met en avant un énorme visuel.

Bon, apple va plus loin puisque leur home ne met en avant qu’un seul produit, alors que là, il s’agit d’un slider, qui fait défiler 10 images XXL.

Sur sélection d’une catégorie, on arrive sur une page comme ça :

Là encore, ce qui est mis en avant, ce sont les photos des produits.

Et voilà la fiche produit :

On est sur une charte qui pousse le minimalisme jusqu’au bout. Il n’y a pas de texte de description sur cette fiche !

Et l’ensemble des actions sont en superposition, par dessus la photo, dont le bouton d’ajout au panier.

En fait, il faut cliquer sur le bouton, en bas à gauche, pour afficher une description en superposition :

Je vous épargne le processus achat, plus classique.

Alors, bonne idée ou pas ? Un des points à valider, c’est si cette façon d’afficher le texte est « SEO friendly ». Qu’en pensent les experts ?

 

 

Barcamp Prestashop le 24 Novembre

Le quatrième barcamp Prestashop aura lieu le 24 Novembre.

8 conférences, 8 ateliers, toute la communauté Prestashop sera là.

C’est une bonne occasion pour glaner de bonnes infos, rencontrer d’autres e-commerçants ou prestataires, …

L’évènement a lieu, comme la dernière fois, à l’Espace Tapis Rouge, 67, rue du Faubourg Saint-Martin – 75010 Paris

Pour s’inscrire, c’est par ici.

 

La guerre fratricide Samsung Apple

Apple maîtrise la chaîne de bout en bout des appareils vendus.

Faux !

Même si apple a une maîtrise assez large de la chaîne verticale, Apple assemble des composants, acheté sur le marché.

Ainsi, les iPhones actuels sont pas mal fournis chez Samsung : écran, mémoire, processeur… Cela fait pas mal !

Mais Samsung a copié Apple, et propose des appareils qui, c’est évident, sont très inspirés par Apple. Il suffit d’avoir en main un produit Samsung pour se rendre compte a quel point la copie est évidente.

Alors les deux boites s’attaquent mutuellement. Apple essaie (et réussi !) de bloquer les ventes du Galaxy Tabs, et Samsung contre attaque en essayant de bloquer les ventes du nouvel iPhone 5 et attaque Apple sur l’usage de brevets, qu’utiliserait Apple dans les iPhones.

C’est étonnant cette situation, et sûrement destructeur pour les deux entreprises.

Au début, on disait que c’est de la « coopétition » : partenaire et concurrent à la fois.

On disait aussi que Samsung est tellement gros que ce ne sont pas les mêmes personnes, les mêmes équipes qui s’occupent de fournir les pièces détachés à Apple et qui conçoivent et vendent les appareils copiés sur Apple.

Mais les choses ont pris une telle ampleur !

Est-ce que Samsung a réellement les moyens d’embêter Apple avec les brevets ? Je n’en suis pas certain. Même si vous allez penser que je ne suis pas neutre, je pense que la situation d’Apple est plus forte.

Aujourd’hui, Apple cherche par tous les moyens à changer de fournisseur. Cela va prendre du temps mais Apple va y arriver.

Pour Samsung, c’est la prévision de revenus en baisse, avec ce client là en tout cas.

Est-ce que cela sera compensé par la vente de smartphones maison ? Peut être, quand on vois les nouveaux terminaux qui sortent…

 

Le tour du monde du e-commerce

Thibaud Clément vient juste de finir ses études, et démarre un tour du monde.

Son idée : avoir une vision plus large, et voir se qui se passe hors de nos frontières.

Son projet: 12 étapes, 12 pays, 12 mois.

Cela devrait permettre de bien prendre le temps, à chaque étape.

Thibaud se finance tout seul son projet, et a refusé les propositions de sponsoring, histoire de rester indépendant et le plus objectif possible.

Bon, c’est tout juste le début de l’aventure, qui commence en chine (tu parles d’un dépaysement !).

Après ? Thibaud pense à se lancer dans le e-commerce (quelle idée 😉 ) mais pas forcément en France.

Je trouve cette initiative excellente. Longue route à Thibaud.

Quel futur pour les systèmes e-commerce

Assez rapidement, quand on développe un système e-commerce (à ma connaissance, je suis le seul à utiliser ce terme, je devrais le déposer 😉 ), on doit découper le système en plusieurs composants.

Mais le découpage est rarement satisfaisant.

Rarement satisfaisant ?

  • La plupart du temps, une bonne partie des fonctions se recoupent entre les différents composants ;
  • L’expérience des utilisateurs métier n’est pas cohérente. Chaque composant propose son propre back office, et les équipes métiers, qui travaillent sur ces interfaces, doivent jongler d’un système à l’autre
  • Les mises à jours deviennent complexes, avec des coûts et des délais difficile à bien anticiper, parce que, comme chaque composant propose sa propre logique, il faut adapter « profondément » l’évolution à chaque composant

Alors, ou est le bug ?

Est-ce une erreur de découper un problème en sous parties ?

Non, bien sûr, le problème n’est pas là.

Le problème est assez simple en fait :

Les modules qu’on assemble ne sont pas réellement fait les uns pour les autres, tout simplement.

L’assemblage est donc un « bricolage ». Je ne mets pas en doute le travaille technique (c’est un autre sujet). Mais brancher ensemble deux systèmes qui ne sont pas fait pour ça, ça ne peut pas faire une solution de qualité (malgrés les promesses commerciales…). Ou alors, le cout devient rédhibitoire.

Alors, quelle est la solution ?

Il faut être pragmatique. Cette solution n’est pas complètement satisfaisante, mais c’est bien souvent la meilleure qu’on ait sous la main. Cette réflexion est donc plus une réflexion « moyen terme » qu’autre chose.

Pour aujourd’hui, une bonne tactique, c’est bien souvent d’identifier un composant « leader », et d’effectuer un assemblage autour de ce composant central.
Un autre élément de qualité, c’est de monter une architecture SOA. Cela permet au moins de définir des contrats clean entre les composants.

Demain, je suis convaincu que les choses vont/doivent changer…

Un des éléments qui doit bouger, j’en ai la conviction, c’est la couverture fonctionnelle d’un composant.
Pour moi, c’est la base d’une architecture à base de plusieurs « briques » : chaque brique doit répondre à une description fonctionnelle très précise. Et qu’on arrête de mélanger interface et coeur du système !
Je n’invente rien en disant ça, j’applique simplement les fondamentaux de la conception modulaire, qui n’ont pratiquement pas bougés depuis 20 ans :
Un module doit définir clairement son interface métier (son API quoi) : c’est le contrat qui doit être rempli par le module.
D’ailleurs, sur des briques plus anciennes, et donc plus mûres, la promesse est bien plus claire. Exemple : un système de gestion de bases de données… gère des données. Les choses sont bien séparées entre le moteur et l’interface. On devrait avoir ce type de séparation, pour monter notre système e-commerce de demain.

C’est un sujet excitant, parce qu’il y a beaucoup à faire, et beaucoup de valeur à apporter !

Si cela vous intéresse d’en savoir plus sur ce sujet passionnant, que vous avez une expertise d’architecte, vous connaissez bien la technique, et vous vous dites que l’aventure est peut être pour vous, contactez moi !

Vente Privée ouvre son site aux US

Vente Privée avait annoncé le lancement des opérations aux US, via un partenaire prestigieux : Amex.

Le site est ouvert :

Une première vente est en ligne, avec la marque Paul et Joe :

On retrouve les codes Vente Privée : de beaux visuels, des produits de marque, à des prix discount.

Maintenant, d’autres acteurs se sont développés aux US sur ce secteur, il va falloir se battre !

Interface or not interface

Discussion passionnante, hier, avec Theodo.

On a pas mal échangé, en particulier sur les interfaces.

Bien sûr, côté Front Office, la question ne se pose pas : on se doit de proposer des interfaces faciles à utiliser, intuitives, rapides, …

Mais la question peut se poser côté back office.

Autant il est évident que certaines fonctions se font très bien via des interfaces, bien souvent web. Exemple : ajouter ou mettre à jour un produit dans le catalogue, ajouter une image, …

Mais pour certaines fonctions bien plus avancées, la question peut se poser.

Exemple : gestion des processus (workflow).

Est-ce vraiment une bonne idée que de développer un moteur graphique, pour représenter des choses aussi complexe que la modélisation des processus ?

Regardons les deux faces du sujet :

Si on a une interface :

L’interface donne un cadre, et elle permet de contrôler qu’on reste dans ce cadre.

Si on prend l’hypothèse que cette interface est bien faite, (hum hum), cela va permettre d’aider l’utilisateur à paramétrer le système.

Exemple intéressant de mon point de vue : le module de paramétrage des promos sur Magento.

Bon, l’exemple est certe particulier, parce qu’on voit bien que le résultat est finalement très très proche d’un programme…

Si on n’a pas d’interface  :

Si on n’a pas d’interface, on va devoir utiliser un langage de description du sujet.

Ce langage peut être un langage hôte (PHP, Java, …) ou une syntaxe XML ou YAML, ou enfinun nouveau langage spécifique.

Si on prend un langage hôte, l’avantage est qu’on peut exprimer directement le problème sous forme d’un programme.

L’énorme avantage est qu’on n’aura pas à développer d’interface, complexe et très cher.

L’inconvénient est qu’on a probablement perdu 99% des utilisateurs métiers du back office. Pour modifier un élément, il faudra faire appel aux développeurs.

Alors, en synthèse ?

C’est un vrai sujet, il faut voir au cas par cas.

en fait, il y a toujours une limite, entre ce qu’on peut faire avec le back office, et ce qui doit être programmé. Certains systèmes essaient de repousser très loin la bascule vers la programmation, mais cette bascule existe toujours, et c’est pas prêt d’être fini : je ne crois absolument pas en « la fin de la programmation » avec la « programmation graphique » type UML… C’est un leurre marketing !

Quelques idées en vrac :

  • Si il s’agit d’une opération répétée régulièrement par les utilisateurs du back office, pas d’hésitation, il faudra une interface, et plus l’opération sera répétitive, et plus l’interface devra être soignée, pour faire gagner du temps aux équipes ;
  • Si l’interface s’avère très complexe, il arrive que la question prenne du sens : développer l’interface peut être très coûteux, et finalement pas rentable du tout, parce qu’en réalité, les utilisateurs n’utiliseront pas cette interface. Exemple : qui utilise un modeleur de processus d’un ETL ? Des informaticiens, qui iraient bien plus vite en programmant…
  • Si on doit « modeler » un problème via un langage de programmation, il est fondamental de développer des couches qui permettent d’exprimer le problème avec un bon niveau d’abstraction. C’est très important, parce que sinon, la mise à jour du programme sera compliqué, cher, … On ne fait pas toujours ce travaille, et c’est un vrai problème !