Catégorie : Technique

  • Une pure neutra­lité du Net est impos­sible et illu­soire

    Pour rendre compte de l’adop­tion par les États-Unis d’une neutra­lité des réseaux Inter­net, France 24 titre « Une pure neutra­lité du Net est impos­sible et illu­soire« .

    Allez compren­dre…

    Alors pourquoi ? J’avais parié sur parce-que-les-terro­ristes, mais ils visi­ble­ment l’ex­pert préfère les argu­ments éprou­vés. Il en est resté à parce-que-la-pédo­por­no­gra­phie.

    Pour Orange, ses données sont beau­coup plus rentables que celles de Skype. Il pour­rait donc déci­der de ralen­tir ou de bloquer les données de Skype pour que les gens utilisent ses services. La neutra­lité du Net prise dans sa forme la plus pure l’in­ter­dit. Évidem­ment, ce prin­cipe doit être nuancé. Il est parfois néces­saire de ralen­tir ou de bloquer certaines données comme par exemple la pédo­por­no­gra­phie.

    Faire en sorte que la pédo­por­no­gra­phie aille moins vite, c’est ça ? euh… je demande toujours à comprendre. D’au­tant que même quand on parle de blocage, je ne vois aucune rela­tion entre le refus de trans­mettre un contenu jugé illé­gal et la capa­cité de favo­ri­ser ses propres services pour raisons commer­ciales.

    Je dis ça je ne dis rien mais la pédo­por­no­gra­phie ici est surtout un joli prétexte qui n’a rien à voir avec le sujet.

    Jusqu’où doit-on fixer le curseur ? Une pure neutra­lité du Net est impos­sible et illu­soire. Il y a certains cas qui doivent être prévus. C’est toute une négo­cia­tion avec les opéra­teurs de télé­pho­nie.

    Bref, on répète le titre mais on s’abs­tient surtout de donner des exemples qui semblent légi­times. D’ailleurs s’il s’agis­sait de pédo­por­no­gra­phie on verrait mal pourquoi on négo­cie­rait pour cela avec les opéra­teurs de télé­pho­nie.

    Bref, d’autres pays l’ont fait, les États-Unis ne sont pas les seuls. Nous nos experts disent que c’est impos­sible et notre presse relaie sage­ment la contra­dic­tion avec la réalité. Bravo Fran­ce24

     

  • Bash­git prompt

    Je bave souvent devant les prompt de termi­nal qu’on voit sur le web mais une fois installé ça fait très gadget, plus gênant qu’autre chose.

    J’ai tout de même ajouté un peu de couleur, pour aider à repé­rer le début de chaque invite quand je remonte dans l’his­to­rique.

    gitprompt

    Reste que quelques indi­ca­teurs ça peut être utile dans un réper­toire git. J’ai tenté oh-my-git mais fina­le­ment je me suis fixé sur bash-git-prompt, avec quelques icônes simples à comprendre. Je regrette juste le nombre de couleurs trop élevé mais ça doit se confi­gu­rer.

  • États-Unis : victoire cruciale pour la neutra­lité du Net

    Les cinq commis­saires qui dirigent la FCC ont consi­déré par trois voix contre deux que l’In­ter­net améri­cain devait désor­mais être consi­déré comme un « bien public » au même titre que le réseau télé­pho­nique, ce qui donne à la Commis­sion le pouvoir de faire appliquer la neutra­lité d’In­ter­net sur le terri­toire améri­cain.

    […] La Commis­sion peut désor­mais inter­dire aux four­nis­seurs d’ac­cès à Inter­net de bloquer arbi­trai­re­ment des conte­nus légaux, de ralen­tir ou d’ac­cé­lé­rer les flux de données sans justi­fi­ca­tion ou de prio­ri­ser certains conte­nus tran­si­tant par leur réseau moyen­nant paie­ment.

    C’est encore plein de détail, le combat est loin d’être fini, et n’a même qu’à peine commencé en Europe, mais c’est la bonne nouvelle de la semaine. Très impor­tante pour l’ave­nir.

  • Trois choses sur lesquelles vous devriez copier Google

    • Takeout : Pouvoir télé­char­ger toutes vos données dans un format stan­dard via un gros fichier zip.
    • Vali­da­tion en deux étapes : La possi­bi­lité d’im­po­ser un aller-retour par SMS ou l’uti­li­sa­tion d’une appli­ca­tion smart­phone en plus du mot de passe, pour sécu­ri­ser correc­te­ment votre compte.
    • Gestion­naire de compte inac­tif : Un système pour donner accès à vos données à une personne dési­gnée à l’avance si jamais votre compte devient inac­tif trop long­temps (avec une alerte pour vous permettre d’an­nu­ler l’opé­ra­tion juste avant qu’elle inter­vienne).

    Parce que pouvoir critiquer ce qui ne va pas implique aussi de pouvoir montrer ce qui est bien fait.

  • Infor­ma­tions person­nelles pour les sites e-commerce

    J’ai­me­rai tant un site e-commerce qui ne me deman­de­rait pas de créer un compte pour faire un achat. Qu’il me soit obli­ga­toire de décli­ner nom et adresse pour par exemple ache­ter un livre en ligne… est plus que gênant

    Je regarde la super lampe déco, je clique sur « ache­ter », je saisis une éven­tuel­le­ment adresse de livrai­son, puis mon numéro de carte bancaire, je valide, et voilà !

    Je n’ai pas besoin de plus pour ache­ter mon pain à la boulan­ge­rie, un lit ou une armoire dans mon maga­sin de meuble, ou un livre à ma librai­rie. Tout ce qui vient en plus avant la fina­li­sa­tion de la commande me fera fuir.

    Parce qu’il y a parfois un besoin d’une rela­tion après vente, je peux comprendre qu’on me demande aussi un numéro de télé­phone ou un email, même si ce n’est pas stric­te­ment néces­saire. On pourra m’y envoyer un jeton d’ac­cès pour me relier à mes commandes ou m’au­then­ti­fier si besoin.

    Je ne vois aucune raison incon­tour­nable d’im­po­ser la saisie de plus d’in­for­ma­tions [en fait si, voir commen­taires]. Je n’ai ni besoin d’un compte ou d’un mot de passe, ni besoin de décli­ner mon iden­tité.

    Rien n’em­pêche de propo­ser la saisie de bien plus d’in­for­ma­tions, mais après la commande, et de façon tota­le­ment option­nelle.

  • Pagi­na­tion sans limit ni offset

    TL;DR: La pagi­na­tion c’est bien™, le faire avec des para­mètres limit/offset c’est mal™.

    C’est très simple à expliquer : Si les données sont mises à jour entre deux requêtes d’une même pagi­na­tion, au mieux vous manquez des données et en visua­li­sez d’autres en double, au pire vous corrom­pez tous vos calculs.

    Hyper­me­dia

    La solu­tion magique c’est que vos API retournent un nombre limité de résul­tats avec des liens dans les entêtes, proba­ble­ment un rel=next pour les données suivantes et/ou un rel=prev pour les données précé­dentes. Le client n’a qu’à suivre les liens.

    En pratique

    OK, je triche parce que je n’ex­plique rien, alors je vais prendre un exemple : Un hypo­thé­tique client Twit­ter sur une hypo­thé­tique API Twit­ter (je m’au­to­rise donc à ne pas préci­ser ce qui se fait sur les API actuelles).

    Lorsque Twit­ter vous retourne les 100 derniers tweets de votre time­line avec les iden­ti­fiants 3245 à 3566, il peut vous renvoyer deux liens dans les entêtes :

    • Un rel=last qui mène en fait vers l’exacte requête que vous avez faite mais avec en plus un para­mètre since_id=3566. Quand vous voudrez rafrai­chir votre time­line, il vous suffira de suivre le lien. Il vous retour­nera les nouveaux messages jusqu’au 3566 non compris, mais jamais ceux que vous avez déjà reçu.
    • Un rel=prev qui mène vers l’exacte même requête que vous avez faite, mais avec en plus un para­mètre max_id=3245. Quand vous voudrez aller cher­cher les messages plus anciens, il vous suffira de suivre le lien.

    Si vous suivez un rel=prev après avoir suivi un rel=last vous fini­rez avec un lien qui contient et un since_id et un max_id, vous assu­rant de combler les trous que vous avez dans votre time­line, sans jamais renvoyer un message en double ni en oublier.

    Si vous souhai­tez faire une synchro­ni­sa­tion complète, il suffit de stocker tous les liens rel=prev que vous rece­vez dans une liste, et d’al­ler les suivre un à un à la fréquence que vous souhai­tez. Vous pouvez avoir un autre fil d’exé­cu­tion en paral­lèle qui suit le rel=last de temps en temps (il n’y en aura qu’un seul à la fois, vous en aurez un nouveau à chaque fois que vous suivez le précé­dent).

    Bon, dans la vraie vie vous aurez géné­ra­le­ment un rel=next (messages juste suivants) plutôt qu’un rel=last (derniers messages), mais Twit­ter est parti­cu­liers : Ça va si vite qu’en géné­ral la prio­rité est d’avoir les derniers messages à date, quitte à géné­rer des trous dans la time­line qui seront comblés plus tard.

    Twit­ter est aussi facile parce qu’on trie toujours pas date, et que l’iden­ti­fiant unique de chaque message est toujours ordonné lui aussi. Ailleurs on utili­sera peut être la date de dernière modi­fi­ca­tion comme pivot pour gérer la pagi­na­tion. L’im­por­tant est que le critère de tri soit cohé­rent avec la donnée utili­sée comme pivot

     

  • Front-end desi­gner ou inté­gra­teur web ?

    On m’a toujours séparé la notion de graphiste web en deux : D’un côté la créa­tion, l’illus­tra­tion. De l’autre le maquet­tage, l’agen­ce­ment, l’er­go­no­mie et les inter­faces.

    Côté déve­lop­peur web il y a les back-end pour le code métier et le code serveur, ainsi que les front-end pour le code inter­face.

    Inté­gra­teur

    Faire du pur HTML/CSS, c’est parfois pris par des déve­lop­peurs front-end, parfois par des graphistes d’in­ter­face. C’est typique­ment ce qu’est l’inté­gra­teur web. Le métier a pris une forte spécia­li­sa­tion depuis 10 ans. Il faut bosser dans un envi­ron­ne­ment très hété­ro­gène, avoir des notions d’er­go­no­mie, beau­coup de connais­sances sur les navi­ga­teurs, y compris tech­nique, faire face à des tech­no­lo­gies en pleine évolu­tion, consi­dé­rer les perfor­mances, etc.

    Je lis les tenta­tives de nommage de desi­gner front-end suite aux inter­ro­ga­tions de STPo. J’avoue avoir un peu de mal parce que ce que j’en lis ressemble quasi­ment parfai­te­ment à ce que j’au­rais nommé inté­gra­teur.

    Has-been ?

    Si je devais envoyer une pique, j’ai l’im­pres­sion qu’il y a un petit complexe face aux nouveaux front-end deve­lo­per, c’est à dire ceux qui font de l’ap­pli­ca­tif JS avec une compé­tence HTML/CSS/HTTP (et déjà, vous notez qu’on manque d’un terme vu que le déve­lop­peur PHP on l’ap­pe­lait déjà front-end deve­lo­per dans pas mal de boites, par oppo­si­tion à celui qui gère le code métier dans des serveurs dans inter­face client).

    Oui il y a une demande de ces nouveaux front-end deve­lo­per, et ça fait perdre un peu de contrats aux inté­gra­teurs qui ne couvrent pas cet aspect. Mais si vous accep­tez de délais­ser ce terme en le quali­fiant de has-been, c’est vous-même qui reti­rez de la valeur au métier. Il faudrait le renfor­cer, commu­niquer dessus, montrer la valeur… D’au­tant que trop de front-end deve­lo­per sont juste­ment du coup plus faibles en inté­gra­tion, à connaitre le support de tous les navi­ga­teurs, les bugs louches de CSS, la compa­ti­bi­lité qui ne se résume pas à la dernière version de Chrome, etc.

    N’ou­bliez pas que c’est comme ça qu’on a créé ce terme dans le web il y a moins de 10 ans. Avant il y avait les webmas­ter d’un côté, et les déve­lop­peurs de l’autre. Le terme d’in­té­gra­teur on l’a juste­ment à l’époque imposé comme l’ex­pert qui savait faire ce code HTML/CSS avec un peu de javas­cript si besoin, et soit une tendance graphiste soit une tendance avec un peu de PHP, souvent les deux.

    Tenter un nouveau terme juste pour rajeu­nir l’image, c’est pour moi une vision non seule­ment très court terme, mais aussi défen­sive en aban­don­nant la valeur au lieu de la renfor­cer à valo­ri­ser le métier.

    Desi­gner

    Reste la ques­tion de l’an­glais, où le terme d’in­té­gra­teur web ne semble pas exis­ter. Propo­ser un terme autre que front-end deve­lo­per peut avoir du sens, mais je ne suis pas convaincu qu’il faille cher­cher dans une spécia­li­sa­tion de desi­gner.

    Je sais que les gens qui parti­cipent à la discus­sion en lien sont quasi­ment tous graphistes *et* inté­gra­teurs. Pour autant, quitte à parler spécia­li­sa­tion des métiers et valo­ri­sa­tion de celui d’in­té­gra­teur, j’au­rais aimé un terme qui regroupe tous les inté­gra­teurs plutôt que de mettre ceux qui débordent côté graphisme dans la case maitresse desi­gner et ceux qui débordent côté program­ma­tion dans la case maitresse deve­lo­per.

    C’est oublier ceux qui sont au milieu et croire que fina­le­ment le métier inter­mé­diaire n’existe pas en soi. Bref, aller là aussi à l’en­contre de la valo­ri­sa­tion du métier spéci­fique d’in­té­gra­teur, en le relé­guant comme une cartouche secon­daire d’un graphiste ou d’un déve­lop­peur.

    S’il est sain de créer des termes pour des spécia­li­sa­tions, ne créons pas des termes pour décrire ceux qui sont à la fois sur deux ou trois spécia­li­sa­tions précises, sinon on ne s’en sortira jamais et on ne fera que divi­ser. Si vous couvrez plusieurs cases – ce qui est non seule­ment très bien mais carré­ment souhaité – dites simple­ment que vous êtes inté­gra­teur et graphiste d’in­ter­faces, ou inté­gra­teur et déve­lop­peur front, ou encore autre chose. Cumu­lez, ne divi­sez pas.

    front-end

    Indé­pen­dam­ment de tout ça, même si on veut clas­ser les inté­gra­teur dans les desi­gner (qui en anglais ne recoupe pas que la notion de graphisme au sens français, je le conçois), je ne comprends pas le quali­fi­ca­tif de front-end ici. Pour le déve­lop­pe­ment il y a du back et du front, mais sauf erreur de ma part le desi­gner s’oc­cupe toujours du front – et ce qu’il fasse de l’in­té­gra­tion tech­nique, de la concep­tion d’in­ter­face ou de l’illus­tra­tion/créa­tion.

    Inter­face desi­gner m’au­rait déjà moins choqué mais je crois que c’est déjà occupé par un poste moins tech­nique. Je n’ai pas mieux à propo­ser mais front-end desi­gner ne me semble rien vouloir dire.

    Je m’amuse de voir que pour une fois, nous avons foison de termes spécia­li­sés en français alors que les anglais n’ont qu’une poignée de termes très géné­riques.

    Et moi ?

    J’ai toujours eu du mal à me mettre dans une seule case, et j’es­père qu’il en va de même pour beau­coup de gens dans le web. Même quand je ne faisais que de la tech­nique, je n’ai jamais su si j’étais déve­lop­peur ou inté­gra­teur.

    J’étais les deux. Certai­ne­ment pas « simple­ment front-end deve­lo­per » dans le sens « inté­gra­teur qui déve­loppe », parce que j’ai toujours vu inté­gra­teur comme une casquette à part entière, qui demande une exper­tise gigan­tesque qui éclipse large­ment le côté « qui déve­loppe ».

    Bref, je ne me retrouve certai­ne­ment pas dans cette sépa­ra­tion des graphistes d’un côté et des déve­lop­peurs de l’autre, en éclip­sant les inté­gra­teurs au milieu. Très dommage.

  • Google Drops Support for Secu­rity Ques­tions

    Google Drops Support for Secu­rity Ques­tions

    …et fran­che­ment il était temps. Ces systèmes de ques­tions person­nelles sont tota­le­ment aber­rants. Bref, merci.

    Il s’agit géné­ra­le­ment de ques­tions dont on peut trou­ver la réponse avec un mini­mum de recherches sur le net. Les amis et les proches connaissent déjà toutes les réponses ou peuvent les obte­nir rela­ti­ve­ment faci­le­ment à force de discus­sion.

    À l’in­verse, mon profes­seur préféré ? La rue de là où j’ai habité petit ? J’au­rais plusieurs réponses possibles. J’hé­site à chaque fois. Il est même possible que certains de mes proches répondent plus rapi­de­ment que moi-même à ces ques­tions – tout en donnant la bonne réponse.

    Un ou plusieurs numé­ros de télé­phone, un ou plusieurs emails, une liste de codes de secours à usage unique… Google fait très bien tout ça. L’avan­tage de ces solu­tions c’est que même si quelqu’un usurpe le compte, le service client peut les réuti­li­ser pour authen­ti­fier le vrai proprié­taire des données.

    Tout au plus on pour­rait imagi­ner de deman­der au service de confir­mer cumu­la­ti­ve­ment par plusieurs moyens, du genre mon télé­phone de bureau, plus le numéro person­nel de mes parents, plus l’email de ma femme. Peu probable que quelqu’un réus­sisse à avoir accès aux trois simul­ta­né­ment sans que je n’en ai connais­sance. Si je perds vrai­ment tous mes accès, cette diffi­cul­tés sera surmon­table.

    Visi­ble­ment des gens se permettent de remettre en ques­tion les pratiques dont le coût est supé­rieur au béné­fice : Je vois des banques désor­mais sans ces claviers virtuels inutiles et je me rappelle Mozilla qui avait arrêté de deman­der le renou­vel­le­ment régu­lier des mots de passe.

    Bon, tout n’est pas gagné partout : Linke­din ne véri­fie pas les emails des nouveaux comptes, et ça ouvre de jolies failles chez tous ceux qui ont un « authen­ti­fie-moi avec Linke­din ».

    Photo d’en­tête sous licence CC BY par Zuerichs Stras­sen

  • Working with desi­gners

    Working with desi­gners

    J’ai lu récem­ment le Working with desi­gners, et ça me donne l’oc­ca­sion de publier une réflexion qui me trotte dans la tête depuis long­temps :

    Vous avez besoin d’un graphiste dans votre équipe.
    En interne, à demeure.

    Oui, on peut très bien faire un peu tout sans graphisme, et trou­ver un pres­ta­taire quand il s’agit quelques fois dans l’an­née de faire une charte, un design ou une illus­tra­tion. Vous manquez juste 80% de la valeur ajou­tée.

    En fait c’est plus large que ça. On peut tech­nique­ment avoir juste un CEO, qui achète des pres­ta­tions de déve­lop­pe­ment infor­ma­tique à une SSII, délègue le cahier des charges à un cabi­net d’as­sis­tance MOA, fait distri­buer la solu­tion par des vendeurs multi­cartes.

    Ça peut même fonc­tion­ner, dans de rares cas. Vous manquez juste la valeur qui est de réflé­chir au produit, de faire des évolu­tions perma­nentes et progres­sives, de lais­ser les gens s’ex­pri­mer, colla­bo­rer, avoir des initia­tives, appor­ter de la valeur, de l’ému­la­tion… On ne parle pas que de produc­tion sur le projet, mais de parti­ci­per et enri­chir la vie de l’en­tre­prise à tous les niveaux.

    * * *

    En régime de croi­sière, pour une boite techno web, vous aurez besoin d’un déve­lop­peur back, d’un déve­lop­peur front, d’un expert produit/métier, d’un graphiste, d’un commer­cial/marke­ting, d’une personne pour le support client, et d’une personne pour gérer l’ad­mi­nis­tra­tif.

    On peut bien entendu parler aussi d’un direc­teur des opéra­tions ou d’un sys admin, mais ils ne font pas autant parti du même coeur mini­mum pour moi.

    Chacune de ces sept personnes vous appor­tera quelque chose dans l’en­tre­prise,mettra de l’huile dans les rouages, même en dehors du projet lui-même.

    *

    Au départ il n’y a pas le choix, il faut porter plusieurs casquettes et faire quelques impasses. Par la suite vous avez tout inté­rêt à ce que les rôles soient poreux, que chacun soit incité à travaillé sur plus que sa petite case.

    Si par contre vous êtes une dizaine et que vous n’avez pas une personne diffé­rente qui joue le guide pour chacun des rôles, vous ne faites pas une écono­mie, vous vous ampu­tez d’une grosse valeur ajou­tée.

    *

    Votre boite n’est pas une boite techno web ? Dans ce cas vous pouvez peut être éviter d’avoir deux déve­lop­peurs distincts, mais il faudra au mini­mum les rempla­cer par un bidouilleur infor­ma­tique à tout faire (au sens noble, si vous croi­sez le terme anglais hacker, c’est de ça qu’on parle), qui devien­dra vite indis­pen­sable.

    Dans ce cadre, j’aime beau­coup la notion « hacker in resi­dence » et « desi­gner in resi­dence » de eFoun­ders. C’est la compré­hen­sion que même parta­gés entre plusieurs projets, pour faire émer­ger de la valeur il faut des gens impliqués à demeure, au milieu des équipes.

    Photo d’en­tête sous licence CC BY-SA par Axel Hart­mann

  • Date dans les API : Préci­ser l’heure et le déca­lage horaire

    Date dans les API : Préci­ser l’heure et le déca­lage horaire

    – Cette méthode donne la date et l’heure de publi­ca­tion
    – L’heure dans quel réfé­ren­tiel ? c’est l’heure UTC ?
    – Non, nous avons des conte­nus français, c’est l’heure française
    – OK, je suppose qu’on parle de la métro­pole et de l’heure de Paris donc. Comment gérez-vous les chan­ge­ments d’heure légale ? Si je prends comme réfé­rence 2h30 du matin le 26 octobre 2014, je risque d’opé­rer certains trai­te­ments deux fois, ou dans le désordre.
    – Pas de problème, nous livrons en réalité à des heures program­mées et il n’y a norma­le­ment pas de livrai­son entre 1h et 3h du matin, donc le cas n’ar­ri­vera pas.

    Je brode un peu mais la conver­sa­tion a déjà eu lieu, plus d’une fois dans ma vie profes­sion­nelle. Je passe sur ceux qui ne compre­naient pas qu’une date devait être soumise aux fuseaux horaires, parce que c’est en réalité toujours une heure (minuit précises) et que le 26 octobre n’est pas le 26 octobre partout en même temps.

    Règle simple :
    Toujours préci­ser l’heure et le fuseau horaire quand on donne une date dans un échange infor­ma­tique.

    On peut argu­men­ter que trans­mettre toutes les heures en UTC pour­rait suffire, et que le fuseau horaire est super­flu. En pratique ce serait oublier une autre règle essen­tielle : « tout ce qui peut être mal inter­prété le sera ». Un jour, quelqu’un pren­dra votre date et l’uti­li­sera comme une date locale et pas une date UTC. Promis, garanti. OK, ça ne sera pas de votre faute, mais si vous voulez que ça fonc­tionne et pas simple­ment renvoyer les respon­sa­bi­li­tés, il va falloir préci­ser.

    Seule solu­tion : Préci­ser le fuseau horaire ou le déca­lage horaire. J’irai même plus loin : Le préci­ser direc­te­ment dans la date elle-même, pour qu’il ne puisse pas être ignoré à la lecture et qu’il ne puisse pas être un simple para­mètre par défaut à l’en­voi qu’on reco­pie sans y penser. La conven­tion de base sur les échanges Inter­net c’est la section 5.6 de la RFC 3339.

    Exemples simples :
    2014–10–26T02:30:59+01:00 et 2014–10–26T01:30:59Z

    L’avan­tage de cette syntaxe est qu’il existe des solu­tions pour la lire dans tous les langages de program­ma­tion, et que toutes ou presque sauront gérer le déca­lage horaire correc­te­ment. Il faut être sacré­ment tordu pour tenter de l’ana­ly­ser soi-même et donc risquer d’igno­rer la partie liée au déca­lage horaire.

    Même à l’écri­ture, préci­ser expli­ci­te­ment le déca­lage horaire va gran­de­ment limi­ter les erreurs d’inat­ten­tion ou d’in­com­pré­hen­sion liées aux ques­tions de fuseaux horaires.

    De toutes façons il faut utili­ser UTC

    Rien ne vous impose pour autant d’ac­cep­ter des heures avec n’im­porte quel déca­lage horaire. L’idée est unique­ment d’avoir une syntaxe expli­cite sur le réfé­ren­tiel utilisé.

    Si vous souhai­tez impo­ser des heures UTC, faites-le. Tout ce que je vous demande c’est d’uti­li­ser une syntaxe expli­cite à ce niveau, et de reje­ter en entrée les dates qui ne seraient pas elles aussi expli­cite quant au déca­lage horaire.

    Photo d’en­tête sous licence CC BY-NC-SA par John Britt