TOTO ARCHIVE

Catégorie : Technology review

21 Sep 2017
ModeleMVC

Comment est organisé le code d’une plateforme

Introduction

Dans ce court article de vulgarisation, nous allons voir quelques thématiques qui vous permettront de mieux comprendre ce que font vos développeurs web et comment ils segmentent leur travail. Pour prendre une comparaison, dans l’industrie automobile, nul ne pourrait imaginer qu’un chef de projet compétent s’adresse à un ingénieur moteur pour lui demander d’expliquer un défaut de production de la carosserie. Dans le dèv, c’est un peu pareil, quand vous créez une plateforme web il y a des types de travaux très différents et mieux vaut bien les identifier, surtout si vous managez une équipe de dév ou êtes product owner.

Le front-end

C’est ce que vous voyez quand vous surfez sur internet sur votre navigateur web. En clair, c’est le rendu graphique. Lorsque le dév front travaille sur le site d’un journal de news, il va être amené à créer un template d’affichage d’articles, dont il réalise la mise en page graphique. Plus techniquement, un template graphique est appelé une Vue (V).
A noter que dans certains cas, un designer a maquetté sur un logiciel comme photoshop ou Indesign le rendu que doit avoir une page web. Dans cas, le travail du front-end est appelé travail d’intégration : le développeur front va intégrer au format web (HTML / CSS / JAVASCRIPT) la page maquettée par le designer au format .psd (photoshop) , ou .indd (InDesign).
Le développeur front doit alors maitriser les trois languages de programmations suivants :

  • L’HTML : pour afficher et organiser par blocs, le contenu brut d’une page
  • Le CSS: pour appliquer des propriétés graphiques comme une couleur, une police, une taille, sur le contenu brut du site
  • Le Javascript : notamment pour créer des animations (une barre de progression, une popup qui apparaît en fondu…)

 

Le back end

Le dév back-end réalise le travaille complémentaire du développeur front. Il réalise toute la logique du site qu’il y a en arrière plan. Reprenons l’exemple de tout à l’heure. Pour pouvoir voir les 5 derniers articles sur la page d’accueil, le dèv back va:

  • Organiser la base de donnée : les articles doivent pouvoir être stockés en mémoire dans une table « articles », selon une structure que le dév a choisi : par exemple il décide qu’un article est organisé avec les propriétés suivante : un article = un titre + une introduction + une image + le contenu texte de l’article. Enfin, il doit rendre cette base de donnée interrogeables de différente manières (et donc créer des fonctions pour être en mesure de lui demander de rechercher un article en particuliers, de lister les articles les + commentés… ). Cette partie du code est ce qu’on appelle le modèle (M)

 

  • Gérer la logique de navigation du site : Quand un utilisateur arrive sur la page d’accueil, le dév back définit que :
    • La base de donnée est interrogée pour récupérer les 5 derniers articles
    • Le bon template graphique de la page d’accueil (la vue home.html par exemple) est affiché avec en paramètre ces 5 derniers articles. Cette partie du code est ce qu’on appelle le controller (C)

Conclusion

L’ensemble de cette logique d’organisation du travail est appelé la logique MVC (Modèle – Vue – Controller). Ce n’est pas la seule logique qui existe mais c’est de loin la plus populaire.
Sur un autre plan, à noter que contrairement aux dév front qui connaissent tous avec les mêmes languages (HTML + CSS + JAVASCRIPT), il existe une multitude de langage possibles et de normes pour coder le back end (php, python, nodejs, ruby…). En plus de la multitude de langages de programmation possibles pour coder le back, il peut exister plusieurs frameworks propres à chacun de ces langages: un framework, c’est un squelette pré-créé qui permet à un développeur back-end de partir sur une logique, une organisation et un ensemble de fonctions déjà existant et qui lui simplifient le travail.

Si vous lancez votre entreprise, sachez que le choix du langage et du framework est souvent un choix stratégique fort qui doit correspondre à la vision de votre entreprise. Par exemple, choisir une technologie propriétaire plutôt qu’un framework populaire par exemple n’est pas neutre du tout et aura rapidement un impact très fort du point de vue business et RH.

11 Nov 2016
node-drupal-queue-comparison

NodeJS versus PHP : des implications business différentes

Choisir NodeJS ou PHP : des implications business différentes pour une start-up

Nous aimons tous NodeJS et sa popularité auprès des développeurs est bien connue, si bien que “Long live asynchronous I/O !” semble être le cri prononcé à l’unisson ces dernières années.
Un cri qui n’est d’ailleurs pas sans fondement car les mérites de l’asynchronisme ainsi que des frameworks Javascript côtés serveur en terme de performance n’ont plus à être démontrés.
Pourtant, NodeJS n’est pas forcément le meilleur choix business pour une start-up web early stage, et cela pour plusieurs raisons.

L’optimisation des performances versus la rapidité et la flexibilité de développement : NodeJS versus PHP.        

« The Lean Startup » d’Eric Ries a popularisé et mis un nom depuis maintenant plusieurs années sur l’intérêt qu’ont les start-up à pouvoir vérifier rapidement la validité de leur modèle, et à pouvoir itérer rapidement. Si on suit une telle logique, malgré l’impressionnante évolution du nombre de libraires Node, l’utilisation d’un framework PHP populaire avec une communauté active et un grand nombre de libraires (comme par exemple Symfony 2, Laravel ou Zend) permet un prototypage beaucoup plus rapide d’une plateforme web qu’avec NodeJS. C’est pourquoi, quand des questions de temps de réponse du serveur ou de performances très pointues ne sont pas là, et ne seront pas une priorité à l’horizon moyen-terme pour la start-up que nous prenons comme exemple, et quand la  dite start-up cherche encore son modèle, et doit par conséquent être en mesure de prototyper rapidement une nouvelle fonctionnalité à faire tester par exemple auprès d’une communauté, l’utilisation d’un framework PHP semble être un choix qui garantisse plus de flexibilité.
Former et faire grandir une équipe en interne, une question RH : NodeJS versus PHP 
Lorsque la start-up n’est plus tout à fait early stage et que l’équipe technologique s’élargit au delà de l’associé technique, la question du recrutement et de la structuration de la production technologique est immédiatement posée sur la table. Une fois encore l’antériorité de PHP offre à la structure plus d’options et de facilité dans le recrutement. Tout simplement, il y a beaucoup de codeurs PHP. Si vous regardez le nombre de freelance sur le site : codeur.com, seulement 800 freelance pour NodeJS versus plus de 17 000 en PHP !

En conclusion : NodeJS versus PHP pour une start-up web early stage : il n’y a pas de choix évident. Cela dépend surtout de la typologie de la start-up. Dans le cas où il y a des contraintes fortes en terme de performance, NodeJS semble être le meilleur choix. Dans le cas inverse, et si la start-up a besoin de flexibilité, de vitesse de prototypage de fonctionnalités, et a des contraintes de temps et d’argent pour structurer rapidement une équipe élargie , PHP s’avère être un choix bien plus judicieux, en tout cas au regard des critères évoqués plus hauts.

01 Nov 2016
api_illustration

Bien choisir son API de paiement

Le monde du numérique compte plusieurs centaines d’API de paiement.
En tant qu’entrepreneur le besoin d’installer une plateforme ou une application mobile de type Marketplace, kickstarter ou Uberlike s’est peut-être déjà manifesté. Commence alors un fastidieux benchmark des différentes offres incluant des critères sensiblement différents en termes, de prix, de service…

Côté pricing en général, la commission de l’API de paiement est présentée de façon claire. En revanche, ce que vous n’avez pas forcément perçu ou risquez de percevoir trop tard concerne les contraintes en terme de fonctionnalités implémentables, généralement très difficiles à cerner en amont. En effet, la longueur des documentations des différents prestataires de solutions de paiement, le nombre de paramètres à prendre en compte ne permettent pas un accès facile aux informations adaptées à vos besoins. Particuliers.

L’objectif de cet article est de produire une brève comparaison entre 4 acteurs majeurs : Paypal (Adaptative Payments), Mango Pay, Braintree, Stripe.
Trois critères, loin d’être exhaustifs, sont retenus :

  • Pricing;
  • Contraintes d’utilisation (géographie, Délai des paiements …) ;
  • Lisibilité de l’API.

Imaginons un cas pratique et étudions-le. Supposons que vous souhaitez créer un marketplace dont le business model est basé sur un système de commission : lorsqu’un membre de votre communauté achète un bien ou un service à un autre membre via votre plateforme, vous prélevez alors une commission A.

I Paypal Adaptative Payments

Pricing : c’est le moins bon de tous pour des tous petits volumes, mais le meilleur dès que votre chiffre d’affaire annuel dépasse les 100 000€.
Nous vous invitons à consulter à partir de ce lien les chiffres précis
https://www.paypal.com/fr/webapps/mpp/paypal-fees

Contraintes d’utilisations : Paypal nous semble de loin le meilleur prestataire sur ce point. Les fonctions de l’API sont utilisables de la même manière quelque soit le pays de domiciliation de votre plateforme.

En clair, et il s’agit là du point le plus sensible du développement technologique, vous devez vous demander si l’API du prestataire de solution de paiement vous permet de gérer les comptes des marchands de votre plateforme de manière lisse et invisible.

En effet, quand vous louez votre appartement chez Airbnb, vous avez l’impression que tout se passe sur la plateforme Airbnb, alors qu’en fait, lorsque vous uploadez vos informations de paiement. Airbnb va les récupérer pour créer un compte Braintree, stocké chez Braintree. Ce compte est crée « Behind The scene ».
En bref, ceci est possible car via son API, Braintree  autorise Airbnb à créer des comptes de paiement à la volée pour ses utilisateurs et permet à Airbnb de modifier, d’administrer, de passer des ordres de paiement entre les comptes ainsi créés, sans restriction.
Néanmoins une condition est à remplir : la plupart des prestataires de paiement, (Braintree compris) ne vous donnent accès aux fonctionnalités de leur API que si votre plateforme est domiciliée aux Etats-Unis.

Paypal se positionne favorablement sur cet aspect puisque les conditions d’utilisation de son API ne dépendent pas du pays de domiciliation de votre plateforme.

Lisibilité de l’API :  Malgré les points positifs mentionnés ci-dessus, la documentation technique est moins bien notée que celle de ses concurrents.
En premier lieu, contrairement à tous les autres prestataires, Paypal  ne contient pas une seule mais plusieurs API(s). Le premier choix technique est donc de choisir laquelle des API  Paypal  est la plus adaptée à vos besoins (Dans l’exemple ci-dessous,  Paypal Adaptative Payments  est à 95% votre choix de prédilection).

Enfin et bien plus « subtilement », certaines fonctionnalités annoncées dans la documentation officielle sont en fait limitées à des partenaires bien spécifiques.
Par exemple, malgré les éventuels espoirs suscités par une lecture assidue de leur documentation, faites une croix sur la possibilité de pré-remplir certains champs du formulaire de paiement lors du « checkout » de votre utilisateur        .

II Mango Pay

Pricing : le prix est tout à fait correct avec ses 1.8% + 0.18€ par transaction
Conditions d’utilisation : Probablement en raison de sa domiciliation en Europe, Mango Pay, comme Paypal, est bien positionné puisqu’il permet aux développeurs d’administrer simplement les comptes marchands. Une restriction au recours à cet API pourrait être lié à votre fond de roulement : lorsque sur votre plateforme un utilisateur A paye un utilisateur B, ce paiement se fait en temps réel alors que la commission collectée par votre plateforme ne vous sera distribuée qu’en fin de mois  .
Lisibilité de l’API : L’api est rédigée de façon très claire

III Braintree

Pricing : la commission est élevée à terme (2,9% + 0,30€) mais il n’y a pas de commission prélevée sur vos premiers 50 000€ de CA.

Contraintes d’utilisation : Votre plateforme doit être domiciliée aux Etats-Unis pour bénéficier de leur API de marketplace.

Lisibilité de l’API : très bonne

IV Stripe

Pricing : 1,4% + 0.25€

Contraintes d’utilisation : Si votre plateforme est domiciliée en Europe, vous pouvez utilisez les API(s) « marketplace », mais la création du compte Stripe ne sera pas invisible pour votre utilisateur marchand, qui sera contraint d’uploader sa carte d’identité et de passer les vérifications réalisées par l’équipe Stripe pour percevoir de l’argent.

Lisibilité de l’API : très bonne

 


Quelques conclusions générales dans le cas où votre plateforme serait domiciliée en Europe:

– Si certains des marchands de votre plateforme doivent pouvoir être localisés en Afrique ou dans certains pays d’Asie, nous vous recommandons Paypal  car il couvre le plus grand nombre de pays.
Vous pourrez parfois être contraints d’avoir des comptes marchands « behind the scenes » notamment pour des marketplaces entre particuliers. Il faudra alors simplifier au maximum le processus de création de compte de vos marchands.
– Si les comptes marchands doivent être créés « Behind The Scenes » (souvent pour des marketplaces C2C, où vos marchands sont des particuliers, où vous devez maitriser l’expérience utilisateur de votre plateforme de A à Z pour simplifier au maximum le procesus de création de compte pour vos marchands), votre choix doit alors se faire entre Paypal et MangoPay. MangoPay est beaucoup plus rapide à mettre en œuvre techniquement mais au final le choix de l’un ou de l’autre doit dépendre de votre sensibilité au pricing et de pouvoir attendre la fin du mois avant de toucher vos commissions.           .
– Dans tous les autres cas, nous vous recommandons Stripe, pour son pricing bas, l’ergonomie du formulaire de paiement par défaut, et sa simplicité de mise en œuvre et de customisation.

 

Michel Jautzy
Fondateur – Bluesquare Computing