 Bon, vous êtes venu pour voir un peu de l'absurdité aujourd'hui. Pour finir la journée, c'est pas mal du tout et je vais vous montrer un peu ce que je voyais avant tous les jours, ce que je continue à voir et ce que je déteste voir toujours. Donc, petite présentation rapide, je suis directeur technique, groupe jeunafrique, donc je travaille avec Benjamin. Je suis développeur depuis maintenant plus d'une dizaine d'années et je développe aussi sur WordPress depuis 2007. Je fais deux, trois plug-ins aussi sur mon temps libre et en fait, je vais bientôt en sortir un sur l'anetics. Donc, si on définissait un peu ce qui était l'absurdité rapidement, Wikipedia nous dit que c'est la différence qu'on fait entre l'expérience qu'on fait, entre ce qu'on imaginait et la réalité. Bon, ça crée de la frustration en général. Un exemple plus concret, ça va être pourquoi, même sous WordPress, 70% des projets se cassent la figure. Pourtant, c'est quelque chose de simple, on apprend assez simplement sur Twitter comment créer des custom possible, etc. Mais pourquoi, malgré ça, on est toujours en scope, hors budget, pas à que le client. Parfois, c'est le développeur, parfois, c'est l'intégrateur, on va voir un peu ça. Donc, si on imaginait un projet, par exemple un site de presse, fort contenu et forte de visite, il y a des différences, corps de métier qui vont intervenir dessus, ça va être la gestion de projet, un DEA, chacun va voir sa vision de la chose, donc le DEA va penser, je vais gagner un award, je vais être reconnu, je vais pouvoir mettre ça sur mon portfolio. Et le chat du projet va dire, c'est bon, je peux faire ce que je veux. Et miracle, j'aurai ma prime parce que mon projet a été livré, attends, et même en avance. L'intégrateur, il veut tout tester, il teste, il va faire un thème premium, en plus, il veut le revendre derrière, il va tester Twitter parce qu'il a vu ça sur d'autres frameworks, et bien sûr, on lui a dit à l'origine qu'il n'y avait pas dit au 6, donc Fleckbox, je vais le tester, c'est le moment, c'est pas toujours le moment en fait. Le développeur à côté, il est full stack, donc il va mettre tout ce qu'il va trouver à côté, il va essayer de le mettre dans Wordpress. Parce que c'est à permitir, c'est l'avantage de PHP, on peut aussi bien faire quelque chose de simple et quelque chose d'usine à gaz. Donc derrière, il va falloir mettre un cache parce que ça ne supporte plus la charge. Vous avez vu ce matin, il y a Rocket, il y a super cache, etc. Et bien sûr, il ne faut pas qu'il y a 15 serveurs, donc il faut aller voir l'adminsystem, il faut aller dire tu prends 3 serveurs parce que ça ne suffit plus. Et le commercial à côté, il s'en fout complètement. Ce qu'il veut, c'est prendre un référenceur, faire du SEO, du multicanal parce que c'est à la mode. Et bien en fait, il a une idée de génie, c'est vendre quelque chose en plus, donc il faut une boutique. Heureusement, maintenant il y a le commerce par exemple avec plein d'admins. Mais malheureusement avant, il n'y avait pas ça. À côté, c'est quand même le principal, c'est le client. Lui, il pense qu'il a un full budget, 500 cas, c'est franchement énorme. Et qu'il y a une équipe de 40 développeurs par exemple. Heureusement, dans tout ça, on est quand même sur WordPress. On est peut-être sauvés. Ce que je vais dire en fait, il vala aussi bien pour WordPress, pour Joomla, pour Drupal, etc. Donc qu'est-ce qu'on voit en fait concrètement sur Internet ? On arrive à trouver comment créer des custom postage, pour les choses à faire, pas faire, aussi bien en termes de sécurité. On a vu ce matin aussi, tout ce qui était HTTPS, HTTPS2, faire les mises à jour, de stratégies les CEO, déploiements sous-guites, ça, ce sera pour demain, etc. On a vu que ça restait quand même dans les 70% des projets qui se castaient la gueule. Si on faisait l'inverse. En fait, ce que je vois aussi tous les jours, c'est ça. Par exemple, je vais faire un thème rapide, je vais prendre Visual Composer, faire de l'ACF, et tout, mais dans quel contexte ? Code source, j'ai pas besoin forcément de faire de l'objet, ça marche très bien avec. Ça marche sans. J'ai à avoir un nouveau développeur, il sait pas forcément tout le legacy qu'il y a. Bon, on va tout mettre dans le fonction.php, bien sûr. Je pense que c'est le meilleur moyen de trouver quelque chose. Le FTP, si on me donne pas de mot de passe de FTP ni PHP 1.000, je développe pas en fait. Je vais pas plus loin, je commence même pas le dev et tout. Ça m'est arrivé plusieurs fois, de répéter plusieurs fois, que moi sur mes installations, je n'ai pas de FTP ni de PHP 1.000. C'est la pire des choses à faire en termes de sécurité. SEO, machin, ça suffit. Et je vais faire des page tags, je sais pas pourquoi, mais on m'a dit qu'il fallait en faire. Mise à jour de WordPress, il y a de la TMA, on a vu tout à l'heure avec Emili. Bizarrement, j'ai quand même des prestataires qui refusent de faire les mises à jour. Pourtant, c'est quand même vital. Le responsif, on verra ça plus tard. Ça ne concerne pas apparemment. Et l'anathique, c'est un morceau de code qu'il faut mettre en bas de page. Il ne faut pas le mettre en début de page apparemment, c'est ce qu'on m'a dit. Franchement, je n'ai pas envie de connaître ces personnes. Et la sécurité, c'est renommé, le plus important, c'est renommé le point PHP Main. Bien sûr, vous éviterez tous les hacks si vous le faites ça. C'est connu. Le HTTP2, j'ai pas de boutique, ça sert à rien. Vous aurez compris que c'était une blague totale. Ces trucs-là, ça peut partir d'un bon principe. Vous ne connaissez pas forcément tout. Évitez de sortir des arguments comme ça devant un client et même en interne parce que vous n'aurez pas de crédibilité. Surtout que c'est vous qui allez récupérer ça. Il n'y a personne d'autre. Et si c'est votre voisin, je peux te dire qu'il ne va pas vous laisser partir tous les soirs. Et surtout, j'entends beaucoup de gens pester contre ce code-là mais qui font rien pour le modifier. C'est-à-dire qu'en fait, eux-mêmes vont refaire le même chose sur leur propre projet et le filer à quelqu'un d'autre. La plupart du temps, ils quittent une entreprise pour aller voir une autre et ensuite dans cette nouvelle entreprise, ils pèsent encore. Et 5 ans après, c'est toujours le même drame. On va voir qu'est-ce qu'on peut faire concrètement pour éviter ça. Je vais vous prendre un cas de figure, assez simple. Chez nous, on appelle ça le cas de Goodebarber. D'ailleurs, apparemment, ils sont dans la pièce. C'est parti d'un principe. On avait une appli, enfin, une legacy, un développeur en Afrique. Je vous laisse deviner la rigueur qu'il y a. C'est comme aller en Inde ou faire ça en Roumanie. Même si parfois, c'est très bien. S'il n'y a pas de rigueur, parfois on arrive au drame. On n'arrivait pas à mettre à jour des cavernis à jour. Et oui, c'était foutu. On s'est dit, il y a Goodebarber. C'est un peu le appresseur, en fait. Pas spécialisé dans WordPress, mais c'est l'idée, c'est qu'on serait assez simplement comme dans WordPress. Une application, ça n'a rien d'éconnête. Enfin, en développement en cocoa, etc. On s'est dit, on va faire ça en attendant, parce qu'on n'a pas le temps, en fait, de développer le projet. Du coup, on a migré toutes les applications dessus. Ça fait, je ne sais pas, plus de 200 000 installations en moins de 2 ans. On n'a pas fait une ligne de code. Ça m'a pris 3 jours à tout configurer. Et pendant ce temps, on acquiert de l'audience. On acquiert des contacts, etc. Qu'on pourra revaloriser par la suite. Vous avez la même chose avec des boutiques, etc. Ça ne sert à rien de faire un majoteau, par exemple, si vous n'avez que 10 produits à faire. Le tunnel paiement, il faut qu'il soit super simple, etc. Donc, c'est valable pour tout type de projet, pas seulement des projets WordPress. L'avantage, c'est que vous pouvez conserver la simplicité qu'a WordPress dans vos processus d'utilisation de sites. Concrètement, à force d'aller trop vite, vous vous perdez pourquoi et quel objectif vous avez fixé à votre site internet. La plupart du temps, vous répondez à un appel d'offre, parce qu'il faut manger. Vous répondez, vous prenez l'expression de besoins et tout. Tels qu'il est, mais sans réfléchir. Est-ce qu'il en a vraiment besoin ? Ça va prendre 20% du budget. Il n'en a pas besoin, il l'a demandé, mais il n'était pas courant. Vous ne l'avez pas conseillé, etc. La première des choses, c'est que quand vous construisez un projet, c'est non pas de faire des jalons, c'est-à-dire poser une date. Vous aurez fait ça pour telle date, etc. Il y a trois ou quatre dates dans le projet. C'est de faire des loups. Chacun des loups doit avoir un objectif précis et clair. Si possible, si vous êtes déjà un site existant, c'est de faire une étude précise de ce qu'on appelle de l'existence. Et de trouver des solutions simples et rapides pour les mettre en place. Ça ne sert à rien d'installer... Pourtant, je suis directeur technique, mais ça ne sert à rien d'installer une usine à gaz, si c'est juste pour faire un plus simple et un gale 2. Si c'est très structuré, etc. On voit presque quand même mélange. Par exemple, tout le PHP, le HTML, etc. ne fait pas des templates, comme on pourrait voir dans un stack framework. Ce n'est pas un molle. Ça permet d'aller plus vite, de faire intervenir l'intégrateur dans le code, etc. sans qu'il se prenne la tête. Et surtout que ces boyclas soient très élevaux de tir. La deuxième chose, c'est de... Pour chacun de ces loups, la plupart du temps, c'est l'interrogation technique. C'est de réaliser des petits crash tests. Ça vous permet d'analyser, savoir vraiment ce qu'on peut faire derrière, avant de dire aux clients, je vous fais ça pendant 3 jours, parce qu'il fallait une date. Vous avez analysé la cible. Ce n'est pas parce que Google vous dit qu'il faut faire ça, qu'il faut le faire. Il ne faut pas que ça soit un préjugé. J'ai fait pas mal de temps. Il fallait créer des page tags pour le référencement. C'était pas utile. Il y a sans doute d'autres choses plus utiles dans votre projet. Un exemple qui pourrait être le cas, c'est la création d'une newsletter. La première chose que vous regardez, c'est combien il y a de personnes qui vont sur votre site. Et qu'est-ce qu'ils utilisent ? Est-ce qu'ils utilisent le mobile ? Le desktop, etc. On sait qu'en Europe c'est le cas, mais en Afrique c'est encore plus le cas. C'est le mobile qui te reste. Un mobile first. Ça marche bien. On peut cliquer sur les titres. C'est facile. Votre client derrière, c'est surtout la version desktop. Les titres sont trop gros. Ce n'est pas l'intérêt. Ce n'est pas les titres. C'est que sur mobile, ça soit cliquable. C'est quand même le mobile. Le but, c'est que nos gens cliquent sur les nositeurs et à aller sur les articles. La deuxième pratique, c'est être pragmatique. La plupart des gens vont faire la tâche qu'on leur donne. Un développeur va développer, un intégrateur va prendre la maquette qu'on lui a donnée, voire même au pixel près. C'est carrément le site d'après. Les avantage d'avoir après, c'est de pouvoir construire assez rapidement quelque chose de très petit d'investir dessus et ensuite de redevelopper quelque chose par la suite. Les thèmes premiums, ce n'est pas non plus un mal. Ça peut vous servir à monter rapidement une vitrine par exemple. Si le site prend, il faut avoir bien structuré l'information derrière. Parce que vous avez forcément un jour ou l'autre, votre premier G. Et surtout, ça vous permet de tester un marché. C'est ce qu'a fait Rocket. Ils ont sorti un plugin, ou Redbug. Ils ont pu le faire évoluer par la suite. C'est pareil avec votre projet. C'est le but des lots. C'est de sortir des premières versions et ensuite, en fonction des retours, il y a le lot numéro 3. Il ne sert plus à rien. Dans le lot 2, on se rend compte que les fonctionnalités qu'on avait sorties dans le lot 1 ne sont plus fiablement si utiles que ça. Soit il n'y a personne qui les utilise, soit c'est contre-productif, quand il y a plein de raisons. Il faut éduquer vos clients aussi à fonctionner par lot. Évitez de dire, je veux une date. Je m'en fous par tous les moyens. Même si tu ne peux pas le dire combien de temps ça va prendre, je vais absolument me dater. Bon, j'aurais fini le lot 1. Dans le lot 1, j'aurais telle fonctionnalité. Je peux te le faire pour temps. Et après, on va avoir le lot 2. Le lot 2, je prévois ça, mais c'est à revoir à fin du lot 1. Donc, c'est la découpage en minot. C'est ce qu'on appelle le micro-projet. Et ça permet aussi de faire des microservices. Si vous vous rendez compte, par exemple, six mois après, une brique de votre site par exemple, nous, on avait un système de fonds qui a apporté des dépêches AFP dans notre site principal sous forme de dépêche. Très pratique pour les journalistes. On s'est rendu compte que la pays reste évoluée et même a été intégrée dans le cœur. On a juste modifié une brique. Ça nous a pris une journée en comprenant les modifications de développement plus la recette. Ce n'a pas été possible avant. Si on avait fait un lot au général, tout a été dans le même plugin, etc. Il fallait s'en doutre adapter, reliver et retester tout, repartir en recette. Pour répondre à Emilie tout à l'heure, c'est à dire, nous, ce qu'on fait, on a mis des tests unitaires d'un point du fonctionnel qui vont interroger le site et vérifier qu'il répond toujours. Ça permet lors d'une livraison de tester que le fonctionnel est toujours là. Ce n'est pas si compliqué que ça. Mais ça évite du temps de TMA derrière et bosser sur d'autres projets. Éviter forcément les visés d'un gaz. Ce qu'on a vu tout à l'heure, le page builder, c'est très bien. Ça vous fait un site très rapidement. Vérifiez juste que la data de votre cœur de métier ne figure pas dans le page builder. Parce qu'en fait, c'est des short-codes. Vous avez un trafic de millions de pages vues dedans, 10 millions de pages vues. Ça servira de cache applicatif parce qu'il ne tiendra plus à charge. Là, je prends l'exemple d'une 404. J'ai nous en fait, on s'est rendu compte qu'une 404 ça peut tuer votre site. C'est drôle, mais quand on découvre ça, c'est la montre. Là, j'ai pris celle du monde. C'est celle qui correspondait le plus à ce qu'on pouvait avoir avant. On le voit, il y a plein de... Il y a des liens, il y a un menu dynamique et tout. Bien sûr, si le journaliste il change le lien, il faut qu'il soit dynamique partout sur le site. Donc forcément, la page fête 404, elle va être dynamique. Donc, ça c'est bien, sauf qu'une 404, c'est toutes vos erreurs. Quand vous faites une migration, c'est 2 millions de pages vues en fin de page qui ont été refermées de Google, qu'il faut rediriger. Il y a une 404. Ça fait tomber votre site. Parce qu'elle n'est pas en cache. Les 404 sont gérées dans WordPress mais par WordPress lui-même. Ça veut dire que quand vous chargez WordPress, WordPress va chercher l'URL. Ne veut pas aller à trouver. Ça fait 64 requêtes par page vues. 64 requêtes. Par exemple, nous on a je ne sais pas, je vais dire 5000 visiteurs à un instant T. Vous multipliez ça et en fait votre serveur MySQL va tomber. Qu'est-ce qu'on avait d'autre ? Les transcientes, on vous apprend. Il faut tout se garder dans la transciente. C'est une mauvaise pratique en fait. 2 transcientes, 3 transcientes, ça va. Se garder tout en transciente, c'est faux. Surtout pas. Parce que ça va interroger votre base de données sauf si vous avez configuré votre cache API. Par exemple, au mois de janvier, on s'a rendu compte qu'on l'avait pas fait au bout de 6 mois de runtime en prod. C'est la boulette. En fait, on l'a configuré. Il n'y a plus qu'une requête. Ça change la vie quand même. 64 requêtes. Une requête. Il y a beaucoup plus de visite qui est supportable pour un même serveur. Ça fait des frais en moins. Tout ce qui est twig et compagnie, nous on a testé. En fait, ça rallonge le temps de développement. L'intégrateur, ça fait une nouvelle technique. C'est bien pour lui, mais à concrètement, on réalise des projets beaucoup moins impinants. Allez surtout, le temps de précompilation en PHP plus long. Sauf si vous mettez du haut cadre. Je vous laisse faire. Et les Nantes. Il part tout. La sécurité, c'est bien. Les Nantes, ça sert à la base de vérifier que vous n'avez pas du cross-cryptime sur un formulaire depuis l'extérieur. Depuis un back-office, ça sert pas à grand-chose. Vous vérifiez par contre que vous êtes bien connecté en amine, que vous avez bien les bons rôles, mais après, si vous n'avez pas de formulaire et que vous n'avez pas de comptes, donc assez près de la tête. Et la sécurité, par exemple, s'il y en a qui supprime leur ennemi, qui renomment les dossiers admignes, comme je vous ai dit tout à l'heure, juste pour cacher la version de WordPress et éviter de se faire hacker. Pensez juste que vous avez le numéro de version WordPress dans vos flux RSS. Donc, c'est inutile. C'est quand même mot de passe. Ça sert pas à empêcher un hacker, il n'y a toujours pas la solution. Il y a bien un moment donné, il va trouver une solution. Les environnements, nous, par exemple, on n'a qu'un seul serveur pour un dimanche pageu. Ça suffit. Avant, on avait cinq serveurs. Donc, c'est juste la qualité de votre code, et surtout la gestion de votre cache, en fait, frontal. Après, si vous avez un site très dynamique, c'est différent, mais ce n'est pas le cas de la plupart des gens. Surtout, ce n'est pas le cas. Donc, si vous voulez une conférence sur le cache, il y a Marie-Balbeur, qui est demain matin, qui fait une conférence dessus plus détaillée. Je n'ai pas le temps en 20 minutes pour le détailler. Mais, par exemple, un CDN comme Cloudflare et tout, c'est pas un serveur de cache. Ça va délivrer votre contenu, par exemple, vos fiches SSS et tout, localement, par exemple, vous êtes en Afrique. Malheureusement, il n'y a pas de CDN en Afrique. Mais en Asie, par exemple, ça va délivrer une version de cache localement plutôt que d'interroger votre serveur en France, etc. J'avais des gens qui mettaient tout dans le CDN. Ça ne servait pas à grand-chose. Et la plug-in de cache, c'est pas toujours la solution. On a voulu tester Rocket, mais en fait, c'était très particulier. Je ne dis pas que c'est mal. Sur d'autres sites, c'est très simple ou complexe, ça peut servir. Mais faites bien attention à l'impact que ça va avoir sur votre code et comment vous le configurez. Malgré une configuration, on savait que nous, quand on l'installait brut et qu'on a fait de 3 configs de base, ça a augmenté le temps de chargement de x2 au lieu de les réduire x2. Du coup, on a développé nos propres outils en interne. Parce que ça n'existait pas si on marchait encore. Ça n'existe toujours pas d'ailleurs. Donc je fasse par mon ennemi système, on fait tout ensemble et tout. Mais souvent, juste un cache applicatif comme Bernich ou Redis, ça vous fait un bien monstrueux de... ça peut augmenter potentiellement diminuer la charge que vous avez sur le serveur et augmenter potentiellement le nombre de personnes que vous pouvez avoir sur votre site. Je vais terminer par ça. Avant, avant de passer d'ailleurs sur WordPress, mal structuré et tout, je ne pouvais pas supporter plus de 1000 personnes sur mon site. Je pensais que c'était d'audience et tout. En fait, il crachait au bout de 1000 personnes. J'ai juste changé tout ces trucs-là. Vous vous adressez à des personnes qui savent utiliser du cache, du vernis et tout. Il y a forcément des gens qui le savent ou pour les... enfin pas des cesse-desi, mais des experts dans ces domaines, des agences. En fait, ils vont vous faire pour vous. Vous vous aidez là-dessus. Globalement, en fait, on est 1.000, 3.000, 4.000 personnes et on peut augmenter jusqu'à... 5.000 personnes. On a fait des piques à 5.000 personnes à instaurter sur des contenus dynamiques. Donc ça peut quand même changer pas mal de la vie. Voilà. Voilà. Juste pour l'information, je n'en ai pas à plus de parler, mais si vous voulez savoir si justement c'est utile de faire des tags, etc. et tout, analyser vos contenus dans un égrecateur de statistiques, par exemple, Granity, XpWeek, etc. Si... On fait quelque chose de sénovateur, si vous voulez vous inscrire, une aide de butto. Merci. Si vous avez des questions.