Le blog des équipes…

  • Accueil
  • e-Commerce
  • Secteur Public
  • Gestion de contenu
  • Application Web
  • Technologies
  • e-Commerce Chine
  • Contact

Certification PHP

Par Romain Six le 27 mars 2006

Debut février j’ai passé la “Zend PHP certification”. Depuis, les mêmes questions me sont souvent posées. Voici donc un petit article à ce sujet.

Qu’est ce que la certification PHP

Zend a mis en place depuis quelques années (2004) une certification PHP.
Celle-ci consiste en une serie de questions permettant de certifier un certain niveau de connaissance et d’utilisation de PHP.

Comment la passer

Tout d’abord vous devez commander le passage de la certification sur le site de Zend ( vous pouvez en profiter pour commander les livres pour reviser et vous préparer à fond).
=> http://www.zend.com/
Un numéro de commande vous sera alors transmis.
Vous pouvez ensuite plannifier une date d’examen via le site PearsonVue.
=> http://www.pearsonvue.com/
Le tout est joué, maintenant vous n’avez plus qu’à vous présenter au centre d’examen que vous avez selectionné le bon jour à la bonne heure.

Qu’est-ce que cela apporte

Pour le certifié :
- Lors d’un entretien d’embauche vous avez une preuve supplémentaire de votre connaissance de PHP (en plus de votre expérience et de votre bonne foi).
- Lors de la préparation de l’examen vous avez pû améliorer votre connaissance de certains domaines de PHP que vous n’aviez pas l’habitude de pratiquer.

Pour l’entreprise :
- Une preuve de la compétence de son équipe technique. En effet , une personne peut justifier un certain niveau en repondant à des questions techniques mais si le client n’est pas en mesure de verifier la justesse des reponses, une certification lui permet d’être “rassuré”.

Est-ce que c’est difficile ?

Tout le monde ne la reussie pas donc elle n’est pas donnée.
J’ai trouvé l’examen plus facile que ce à quoi je m’attendais (peut être que j’avais pris un bon petit dejeuner …. ).
Je me suis renseignée sur plusieurs sites afin de connaitre le niveau de difficulté de la certification.
Les avis son très partagés mais ceci est aussi dû au fait qu’elle a évoluée et est plus difficile qu’au tout debut.
Toujours est-il qu’il n’y a que 20 certifiés PHP en France à ce jour et 1138 dans le monde.

Mon avis

Je m’attend à des remarques comme “je sais developper en Php, j’ai fais des applications, des sites qui fonctionnent très bien et pourtant je n’ai pas de certification”.
Effectivement, le fait de ne pas être certifié ne veux pas dire que vous ne connaissez rien en PHP mais comme ennumérés plus haut, il y a de nombreux avantages a être certifié. Il y a beaucoup de developpeurs PHP de très grande qualité, il y en a aussi beaucoup qui “bidouillent”.
Repondre à des questions ou montrer ses créations n’est quelque fois pas une preuve suffissante de qualité.

Personnellement je trouve comme beaucoup d’autres personnes que les questions posées lors de l’examen sont quelque fois un peu “tordues” mais c’est ce qui permet de faire la différences entre plusieurs niveaux.

Je trouve egalement un peu dommage que la certification ne porte que sur Php4.
Php5 est de plus en plus utilisé et la version 6 commence à pointer son nez ….
Après on peu argumenter que les principaux outils open source tournent sous Php4 et que si on connait bien Php4 on peut s’adapter aux version suivantes… c’est à debattre.

A savoir

- Le test est en anglais. Evidement c’est important de comprendre les questions pour bien repondre mais le niveau d’anglais n’est pas très elevé et les questions sont dans le même style ou du moins reprennent le même vocabulaire que celles posées dans les livres d’entrainement.
- Les tests portent sur PHP4
- Vous avez la réponse (examen reussi ou pas) directement à la fin du test.
- Un annuaire “yellows pages” , est disponible sur le site de Zend et permet de visualiser l’ensemble des personnes certifiées à ce jour.
=> http://www.zend.com/store/education/certification/yellow-pages.php

N’hésitez pas à me faire part de vos questions / commentaires

Commentaires
Pas de Commentaires »
Catégories
Non classé

Like


la Chine s’attaque aux SPAMS

Par Cyril Drouin le 16 mars 2006

La Chine a annoncé mardi qu’elle allait s’attaquer prochainement aux polluposteurs pour contrer le nombre toujours grandissant de polluriels qui sont envoyés de son territoire, peut-on lire dans un article de l’agence de presse américaine Associated Press.

Le gouvernement communiste compte ainsi, par une nouvelle loi, interdire aux polluposteurs l’envoi à des fins commerciales de polluriels non sollicités par les internautes. De plus, tous les courriels commerciaux qui sont sollicités par les internautes devront aussi dorénavant porter les mentions “advertisement” ou “AD” dans le sujet du courriel.

Un volet de cette loi du gouvernement communiste s’attaquera aussi aux utilisateurs envoyant des messages “illégaux” avec des téléphone cellulaire (messages SMS), sans toutefois spécifier ce qui est considéré “illégal” par le gouvernement chinois. Certains analystes politiques estiment que cette mesure pourrait inclure les messages à caractère politique considérés comme subversifs et incitant au désordre social.

En se basant sur d’autres pays avec des lois similaires, ces analystes doutent que la nouvelle législation pourra réellement réduire le nombre de polluriels. Selon eux, cette loi servirait plutôt à masquer une nouvelle atteinte du gouvernement chinois à la liberté d’expression. Plusieurs manifestations récentes ont d’ailleurs été organisées par le biais de messages SMS, ce qui semble déranger le gouvernement communiste.

Le gouvernement chinois n’a d’ailleurs pas voulu spécifier quelles mesures coercitives allaient être utilisées contre les personnens qui ne respecteraient pas la nouvelle législation. Les analystes politiques estiment que cette loi risque d’être très sévère. À titre d’exemples, Li Zhi et Shi Tao, deux cyberdissidents chinois, ont respectivement été condamnés à 8 et 10 ans de prison pour avoir écrits des messages considérés subversifs sur le Web entre 2003 et 2005.

(source branchez-vous)
Commentaires
Pas de Commentaires »
Catégories
Non classé

Like


Faut il passer au libre ?

Par Cyril Drouin le 16 mars 2006

Les logiciels libres ont réussi leur percée. Le phénomène, annoncé depuis longtemps par certains, minimisé ou redouté par d’autres, a fini par se faire une place dans les systèmes d’information et les esprits.

Je ne reviendrai pas sur les succès médiatiques de la suite bureautique OpenOffice.org, récemment adoptée par la Gendarmerie Nationale, ou du navigateur web Firefox, qui ose (enfin !) remettre en question le monopole d’Internet Explorer.
Inutile également de s’appesantir sur la progression fulgurante des serveurs d’application Open Source (PHP, Tomcat, JBoss, etc.) ou de vanter les mérites d’Apache, qui détient près de 70% de parts de marché parmi les serveurs web.

Tout le monde aujourd?hui « sait » que les logiciels libres sont moins chers, plus fiables et plus flexibles que leurs équivalents propriétaires et qu’ils redonnent une indépendance aux équipes informatiques. Bref, l’Open Source, c’est « in », et tant pis pour ceux qui n’ont pas pris le train, ils le paieront tôt ou tard.

Et pourtant… Nombre de sociétés, de toutes tailles, n’ont pas franchi le cap et persistent dans l’utilisation de produits éditeurs. Il y en a même (nous en croisons tous les jours) qui choisissent encore de démarrer des projets sur des technologies propriétaires et fermées. C’est que, malgré tout, l’Open Source continue de susciter des inquiétudes et des interrogations.

Pourquoi il ne faut pas avoir peur du libre ?

Généralement, les raisons invoquées à l’encontre de l’Open Source sont de trois ordres :

  • absence de support de la part d’un éditeur
  • inquiétudes liées à la pérennité du produit
  • incertitudes autour de la licence.

Reprenons point par point ces arguments et voyons s’ils sont fondés.

Le support

La question du support est essentielle lors de l’acquisition d’un programme informatique. Tout le monde rêve de logiciels simples à installer, à configurer, à utiliser et se mettant à jour tout seuls, mais malheureusement la réalité est toute autre : il y a toujours des bogues ou des failles de sécurité à corriger, sans parler des « killer features » apparaissant dans les versions ultérieures. Aussi, l’entreprise qui dispose d’un logiciel doit avoir un interlocuteur prêt à le faire évoluer.

Or, dans le cas d’une solution éditeur, la réponse est simple : soit celui-ci assure lui-même le support, soit il faut passer par un partenaire ; mais dans tous les cas, on est sûr de ne pas se retrouver dans une impasse.

Lorsqu’on choisit de partir avec une application Open Source, deux cas de figure se présentent :

  • soit le projet Open Source est soutenu par un éditeur (comme c’est le cas pour les distributions Linux RedHat ou Mandriva, la base de données MySQL, le serveur d’applications JBoss et d’un nombre toujours plus grand d’applications) qui assure des prestations de service et de support (c’est même précisément ce qui le fait vivre), et on est alors dans la même logique que pour un produit propriétaire ;
  • soit le projet n’est soutenu par aucun éditeur (cas de tous les projets de la fondation Apache notamment, mais aussi d’une multitude d’initiatives isolées), et dans ce cas il faut avoir recours à un prestataire de service qui fera office de support, sauf si le service informatique interne est en mesure d’assumer ce rôle. A noter que cette dernière éventualité n’est pas à écarter d’office : la plupart des projets libres « vivants » se caractérisent par une communauté active d’utilisateurs et de développeurs, ainsi qu’une documentation abondante, facilitant leur appropriation.

Dans tous les cas, la logique est différente entre un produit éditeur et un produit Open Source : si l’éditeur s’engage généralement à corriger les anomalies bloquantes détectées (le plus souvent moyennant finances et dans des délais prédéfinis), le support Open Source n’impose que rarement des obligations de résultat, le prestataire s’engageant seulement à répercuter les corrections apportées par la communauté. Ce qui ne veut pas dire que le support sera de moins bonne qualité : on constate en général que les communautés Open Source sont beaucoup plus réactives que les éditeurs…

La pérennité

Deuxième argument souvent dressé à l’encontre des logiciels libres : la pérennité des produits. C’est à mon sens le moins fondé des trois : on ne compte plus les exemples d’éditeurs ayant abandonné une solution, soit qu’ils aient décidé de recentrer leur activité, soit qu’ils se soient fait racheter, ou bien encore qu’ils aient tout simplement mis la clé sous la porte. L’exemple le plus parlant est sans conteste Netscape, qui n’a vu sa survie que grâce à la mise en Open Source de son navigateur, devenu depuis Firefox et rencontrant le succès que l’on sait.

Alors, cela ne veut pas dire que les logiciels libres sont plus pérennes que les logiciels propriétaires, loin de là : on ne compte pas non plus les innombrables projets libres qui sont laissés à l’abandon. Il y a toujours une grosse part d’incertitude quant à la pérennité d’une solution sur deux, trois, cinq ou dix ans.

Mais il est plus facile d’évaluer le risque avec un produit libre qu’avec un produit éditeur : la pérennité d’une solution éditeur dépend souvent de la survie de cet éditeur, ainsi que de contraintes économiques ou politiques qui peuvent être totalement extérieures au produit (l’opinion courante qui consiste à croire qu’il est plus pérenne de partir sur une solution portée par un gros éditeur est infondée : les gros éditeurs abandonnent aussi des produits, ainsi Visual Source Safe de Microsoft, délaissé au profit de Team Foundation) ; au contraire, la survie d’une solution Open Source est beaucoup plus liée aux qualités intrinsèques du produit ; la taille et la vivacité de la communauté d’utilisateurs et de contributeurs sur un projet Open Source donne une bonne indication quant à sa pérennité, chose que l’on peut plus difficilement mesurer avec une solution éditeur ; enfin, la viabilité d’une solution est fortement liée à sa solidité technique, que ce soit pour un logiciel libre ou éditeur ; or cette solidité n’est appréciable que lorsqu’on a accès aux sources (même s’il faut reconnaître que très peu d’intégrateurs le font réellement, ce qui est regrettable).

La question de la pérennité se pose donc dans les mêmes termes pour une solution propriétaire et pour une solution Open Source. Mais elle est généralement plus facile à apprécier dans ce deuxième cas.

La licence

Précisons d’emblée qu’il n’y a pas une licence Open Source, mais plusieurs centaines ! Les seuls points communs entre toutes ces licences sont : la mise à disposition gratuite du produit; la possibilité de modifier le code source.

La plus connue (et la plus répandue) est la licence GNU GPL (General Public License). Elle contient une clause obligeant l’utilisateur à reverser dans le domaine public toutes les modifications qu’il apporte au logiciel, et c’est généralement ce qui fait peur aux entreprises, qui ne souhaitent pas étaler sur la place publique des informations pouvant se révéler précieuses pour leurs concurrents. D’autant plus qu’à partir du moment où seulement une partie d’un programme utilise du code placé sous GPL, automatiquement tout le reste du programme se trouve « contaminé ».

En réalité, ce qui apparaît lorsqu’on lit soigneusement la GPL, c’est que cette contrainte n’est valable qu’à partir du moment où l’application est diffusée à des tiers. Or il est rare qu’une entreprise distribue son programme à d’autres entités. L’utilisation au sein d’une application web, par exemple, n’est pas assimilée à de la « diffusion ».

Le seul cas où la GPL peut être trop contraignante, c?est lorsque justement l’utilisateur souhaite distribuer son programme (le vendre par exemple). Dans ce cas, il est dans l’obligation de mettre à disposition les sources également.

Mais si la GPL couvre aujourd’hui une majorité de logiciel libres (dont tout le système d’exploitation Linux, notamment), il faut préciser que nombre de projets utilisent d’autres licences (les licences Apache, Mozilla, FreeBSD, etc.) qui n’ont pas cette vertu « contaminante » et qui n’obligent pas à rendre publiques les modifications, quel que soit l’usage qui est fait du programme.

Quoi qu?il en soit, il est primordial de bien se renseigner sur l’adéquation de la licence à ses propres besoins avant de se lancer dans les développements.

Pourquoi il ne faut pas faire le choix du libre ?

Je sens parmi mes lecteurs comme un soupçon d’étonnement : après toute cette démonstration visant à prouver qu’il ne fallait plus avoir peur des logiciels libres, il va maintenant nous convaincre qu’il ne faut pas les utiliser ?

Ca sent l’arnaque de consultant, la manipulation n’est pas loin… Rassurez-vous, le but de mon propos n’est pas de vous prouver tout et son contraire : si je pense qu’il ne faut pas craindre les logiciels libres, c’est qu’à mon sens ils peuvent réellement apporter un plus aux entreprises.

En réalité, ce titre volontairement provocateur doit être compris ainsi : aujourd’hui, il ne faut pas « faire le choix » du libre, c’est à dire décider de passer au libre parce que le libre c’est bien, c’est dans l’air du temps et ceux qui n’ont pas compris ça ne sont plus dans le coup. Non, le libre ne doit pas être vu d’un point de vue idéologique, dans le contexte d’une entreprise en tout cas (si ensuite vous choisissez de privilégier les logiciels libres à titre personnel parce que vous voulez promouvoir l’esprit de partage et de liberté transfrontaliers, cela ne regarde que vous – personnellement je n’utilise que des logiciels libres depuis des années !). Bref, aujourd’hui, on ne doit pas décider de « passer au libre », mais plutôt choisir pour chaque besoin la solution la plus appropriée, qu’elle soit libre ou propriétaire.

Le risque idéologique

C’est qu’un choix trop précoce, que je qualifie donc d’idéologique, par opposition à un choix argumenté et pragmatique, peut se révéler catastrophique.

Prenons un exemple : dans le domaine de la gestion de contenu web, deux technologies prédominent aujourd’hui : Java et PHP. Le choix de l’une ou l’autre de ces technos est impactant sur le système d’information dans sa globalité : infrastructure, compétences, intégration d’applications, etc. Il intervient donc souvent en amont, devenant du coup un pré-requis pour le choix de la solution de gestion de contenu. Or, ceux qui connaissent un peu ce secteur savent que si, dans le monde PHP, il existe de très bon outils Open Source (SPIP, Typo3, eZ publish, etc.), en revanche, en Java, les meilleurs produits sont propriétaires (Noheto, Vignette, Jahia, etc.). Il existe bien des projets libres (Lenya, eXo Platform, Graffito, etc.), mais ceux-ci n’ont pas encore atteint le niveau de leurs concurrents éditeurs. Décider par avance de partir sur une solution Open Source en Java risque d’engager des coûts de développement bien plus importants que les coûts de licence des outils propriétaires.

Bien sûr, il arrive que ce choix de « passer à l’Open Source » émane d’une directive groupe ou ministérielle. Mais les directives bien écrites sont celles qui préconisent le choix de solutions Open Source, sans pour autant fermer la porte aux éditeurs. Et, dans le cahier des charges, il est préférable d’écrire que les solutions à base de logiciels libres seront privilégiées plutôt que d’imposer ce choix à l’avance. Seule une analyse précise des besoins et des réponses apportées par les solutions, tant sur le plan fonctionnel, technique, qu’économique, pourra en définitive permettre de trancher.

Comparer libre et propriétaire

Tout cela est bien joli, mais beaucoup doutent de la simple possibilité de comparer un produit libre avec un produit éditeur. Autant, sur le plan fonctionnel et technique, cela ne pose aucun problème, autant, sur les aspects économiques, les choses ne sont effectivement pas si simples.
C’est que généralement, les grilles de critères élaborées par les consultants sont adaptées aux solutions éditeurs. Comment évaluer le vendeur d’un logiciel, quand celui-ci n’existe pas ? Ou la réactivité du support lorsque celui-ci est (indirectement) assuré par une communauté ?

Par ailleurs, ces fameuses grilles de critères font souvent la part belle à tout un tas de « nice-to-have features », autrement dit des fonctionnalités un peu « gadget » qui ne sont absolument pas requises, mais qui pourraient éventuellement apporter un petit plus. Elles ne devraient intervenir dans le choix que dans un second temps, une fois que les fonctionnalités vraiment nécessaires ont été évaluées. Le problème, avec les solutions éditeurs, c’est qu’une part importante du budget est consacrée à ces touches plus marketing que vraiment utiles, et les décideurs se laissent parfois séduire par des équipes commerciales habiles. Alors que c’est un aspect totalement absent des logiciels libres, pour lesquels on peut être sûr que chaque fonctionnalité implémentée répond a un besoin réel. Mais lorsqu’on regarde de haut la liste des fonctionnalités, c’est sûr, la solution éditeur semble plus attractive !

Bien souvent, une telle analyse fait ressortir la solution Open Source comme étant a priori moins coûteuse que la solution propriétaire, mais plus risquée. L’évolution va dans le sens d’une diminution des coûts des solutions propriétaires (ce, notamment grâce à la concurrence des logiciels libres), et d’une plus grande maîtrise des risques associés aux solutions Open Source (grâce à la multiplication des retours d’expérience).

Comparaison des risques et des coûts entre projets libres et propriétaires

Attention toutefois à ne pas tomber dans le piège qui consiste à croire que le libre est forcément moins cher que le propriétaire. L’analyse économique ne se limite pas aux seuls coûts de licence : il faut prendre en compte les coûts de développement, d’intégration, de support, mais aussi la pérennité, les évolutions, etc. Une telle analyse est généralement complexe à mener.

D’où la nécessité de se faire accompagner par des équipes connaissant parfaitement les deux mondes, capables d’évaluer la réactivité d’une communauté, de faire la part des choses entre les fonctionnalités vraiment utiles et les autres, etc. J’ai eu l?occasion de travailler récemment avec une équipe chinoise, sur une mission de conseil devant aboutir au choix d’une solution. Les produits étudiés étaient tous propriétaires, sauf un logiciel libre (qui justifiait en fait ma présence au sein de l’équipe). La partie la plus difficile a été de convaincre les Chinois que l’on pouvait comparer des produits propriétaires avec des produits Open Source. Il a fallu se battre pour adapter la grille de critères, en la faisant davantage coller aux besoins réels du client (pour l’anecdote, ce dernier a finalement décidé de partir sur la solution libre, après un prototypage concluant).

L’Open Source rentre dans le rang

Finalement, tout ce discours tend à montrer qu’il ne faut plus pointer du doigt les logiciels libres en les présentant comme un phénomène en marge du reste du monde : ils ont atteint suffisamment de maturité pour « rentrer dans le rang ».
D’ailleurs, pour les logiciels libres soutenus par des éditeurs, la distinction entre produit Open Source ou éditeur est subtile ; et de plus en plus d’éditeurs vont dans le sens de l’ouverture d’une partie de leurs sources, généralement les couches les plus basses (framework, formats d’échange, etc.), répondant ainsi à une demande croissante des utilisateurs.

Lorsqu’un projet s’annonce, il ne faut pas commencer par se poser des questions existentielles sur le choix d’une solution Open Source ou pas. Il faut simplement inclure dans l’étude préalable les solutions qui paraissent les plus intéressantes, qu’elles soient libres ou propriétaires.

C’est l’analyse économique qui déterminera si « faire le choix du libre » est pertinent ou pas.

Commentaires
Pas de Commentaires »
Catégories
Non classé

Like


PHP6

Par Cyril Drouin le 12 mars 2006

Les principaux outils open source commencent à peine à evoluer pour être compatible Php 5 que la version 6 fait déjà parler d’elle.

(http://www.01net.com/article/295992.html)

Commentaires
Pas de Commentaires »
Catégories
Non classé

Like


Google et la Chine s’entendent sur la censure de son moteur de recherche

Par Cyril Drouin le 11 mars 2006

ans une décision qui choque plusieurs organismes sur la liberté de parole dont Reporters sans frontières, Google a annoncé mardi que la compagnie avait trouvé un terrain d’entente avec le gouvernement chinois sur la censure de son moteur de recherche, argumentant que c’est mieux d’avoir un moteur de recherche censuré que de ne pas en avoir du tout.

“Google.cn”, qui sera lancé mercredi, contiendra des notes dans le bas des pages de résultats de recherche indiquant si le contenu est censuré par les autorités chinoises, a indiqué un porte-parole de la compagnie californienne. Google compte ainsi satisfaire les lois et réglementations sévères du gouvernement chinois. Les services Gmail et Blogger ne seront d’ailleurs pas offerts tant que la compagnie n’aura pas trouvé un moyen efficace de s’assurer de respecter la législation du gouvernement communiste.

Avec une population de 1,3 milliard d’individus, dont 111 millions sont connectés à Internet, plusieurs compagnies sont donc tentées de se plier à la sévère législation des autorités chinoises pour avoir accès aux grandes possibilités commerciales qu’offre la Chine. Google a d’ailleurs ouvert récemment un centre de recherche et développement en Chine et détient une partie du moteur de recherche le plus populaire chez les Chinois, Baidu.com.

Commentaires
Pas de Commentaires »
Catégories
Non classé

Like


BYSOFT est une agence d'Ingénierie Internet Interactive. Nous accompagnons nos clients dans leurs projets E-commerce et Portails en gestion de contenu.
Nous offrons une couverture globale de services : Conseil, Agence Web, Ingénierie, Hébergement et Génération de trafic.
        

Technologies

  • Ajax
  • DotNetNuke
  • Drupal
  • eZ Publish
  • Flex
  • Internet
  • Joomla
  • Magento
  • MySQL
  • OsCommerce
  • PHP
  • Prestashop
  • Spip

Archives

  • 2012
    • janvier
    • février
  • 2011
    • janvier
    • février
    • mars
    • avril
    • juin
    • juillet
    • septembre
    • octobre
    • novembre
    • décembre
  • 2010
    • janvier
    • février
    • avril
    • mai
    • juin
    • juillet
    • août
    • septembre
    • octobre
    • novembre
    • décembre
  • 2009
    • janvier
    • février
    • mars
    • avril
    • mai
    • juin
    • juillet
    • août
    • octobre
    • novembre
    • décembre
  • 2008
    • février
    • mars
    • avril
    • mai
    • juin
    • juillet
    • août
    • septembre
    • octobre
    • novembre
    • décembre
  • 2007
    • janvier
    • février
    • mars
    • avril
    • mai
    • juin
    • juillet
    • août
    • septembre
    • octobre
    • novembre
    • décembre
  • 2006
    • janvier
    • février
    • mars
    • avril
    • mai
    • juin
    • juillet
    • août
    • septembre
    • octobre
    • décembre
  • 2005
    • octobre
    • novembre

Derniers tweets

  • 15-02-2012
    Nouvel article sur le blog des équipes: "la nouvelle version 1.12 de Magento Enterprise" http://t.co/J8JXCQM8
    ReplyRetweetFavorite

  • 14-02-2012
    Sur le blog des équipes : Brève Drupal 8 - HTML 5 http://t.co/EqlVMjQl
    ReplyRetweetFavorite

  • 09-02-2012
    Nouvel article sur le blog de nos équipes: "Mettez des accents dans votre nom de domaine.fr" http://t.co/WEHCUTE8
    ReplyRetweetFavorite

@BysoftFrance
Le site de l'agence | Nous contacter | rss RSS | Twitter Twitter