xulops a écrit 319 commentaires

J’arrive un peu après la bataille, désolé, mais répondre un tartine comme celle-là demande un peu de temps pour se décider (à y consacrer le temps, justement) et à la rédiger (surtout avec mon clavier qwerty, merci iBus, tu plantes de temps en temps avec le chinois mais je t’aime quand même).

J’ai lu beaucoup de commentaires disant que 2000 euros par an, c’est que dalle au regard du confort et de la sécurité (sauvegardes, remise en route après désastre…). Ca se discute, et se comprend surtout si le CA est élevé, que la boîte se porte bien. Dans le cas évoqué, c’est clairement énoncé que c’est cher pour lui, et précisé ensuite que la situation financière de la boîte n’est pas rose, en partie à cause du confinement. De plus, le gars a un désir de changement. Peu importe ses motivations, un désir de changement se respecte, se doit d’être pris en compte.
Je suis donc d’avis de ne pas le dissuader de changer, sous prétexte que 2000E/an c’est peu. Personnellement, pour une TPME de deux personnes (le comptable ne doit pas se connecter souvent), je trouve même que c’est très cher.

Je vais vous raconter une petite aventure de la fin d’année dernière, ne m’en veuillez pas si c’est long :
Je vis en Chine, et j’ai décidé, avec une personne chinoise, d’ouvrir un petit resto vendant à la fois des nouilles (de blé, de riz, …) et des pâtisseries (pancakes, muffins, gaufres…). Les lois chinoises étant particulièrement inexistantes pour ce genre d’activité, pas de logiciel de caisse infalsifiable, pas de TVA, pas de taxes à payer, … ce que tu gagnes est direct dans ta poche.
Voulant faire des statistiques de ventes, par produit, par jour, tenir un peu un stock de matières premières, des dépenses, j’ai développé un site web pour usage en plein écran sur tablette android. Deux tablettes, une par cuisine (une cuisine pour les nouilles, une cuisine pour les pâtisseries),et éventuellement saisie des commandes en salle sur mobile. Le « serveur » est un simple Raspberry Pi4 (Apache/PHP/Maria DB). Je n’ai pas cherché de solutions existantes pour deux raisons : je voulais m’amuser à le faire moi-même, et un truc qui permette la saisie de commandes de plusieurs endroits en affectant les lignes aux cuisines respectives, avec un cas spécial pour les articles pouvant être fournis par les deux cuisines (boissons par exemple), ce n’était pas gagné. Et j’en rajoute même une troisième : pas question de mettre 2000 euros par an pour ça.
Tout ça pour dire, une petite entreprise de deux ou trois personnes, il n’y a pas besoin d’une salle serveur et de beaucoup de matériel. Deux tablettes et deux raspberry pi4, surtout en Chine, ça ne va pas loin (de mémoire moins de 300 euros). J’ai bien écrit deux Raspberry, parce que justement en cas de panne, ça prend 2 minutes à changer. Pour les sauvegardes, un script sur le Pi qui dump la base de données et copie dump, codes et logs sur une clé USB toutes les 5 minutes pour la sauvegarde locale. Le Pi de secours a déjà une carte SD avec tout installé. Si la carte SD de production plante, changement de carte SD, recopie des fichiers de la clé USB et ça repart. Il faut aussi des sauvegardes régulières vers un site distant, dans mon cas un rsync vers un serveur toutes les heures. Ce serveur distant est aussi backupé, mais là on s’éloigne du sujet.
Donc voilà, héberger en local demande bien entendu des compétences, mais pas un investissement financier énorme, c’est même plutôt ridicule. Un raspberry Pi peut très bien faire tourner ce genre de site pour plusieurs utilisateurs simultanés. Je n’ai pas testé à fond, mais dans mon cas il glandait 99.9999 % du temps. Aucun problème pour mettre une instance Dolibarr dessus.

Pour revenir au cas de l’OP, je comprends très bien qu’il ne veuille pas non plus y mettre 2000 euros par an, surtout s’il ne mange que des pâtes tous les jours. Et je ne lui conseillerai pas d’héberger en local s’il n’y connaît rien, même si c’est tout à fait possible sans se ruiner mais en investissant beaucoup de temps dans l’administration système.
Il ne lui reste donc uniquement l’offre cloud : une instance de l’ERP qu’il choisit, et dont il n’aura pas à s’occuper de la maintenance et des backups. Mais encore faut-il qu’il choisisse !
Le choix se fait avant tout sur l’adéquation de ses besoins avec les fonctionnalités de l’ERP. Puis vient le prix, et ensuite d’autres critères comme l’ergonomie, la facilité de joindre un interlocuteur, …

Pour l’adéquation des besoins, c’est difficile de le conseiller, on n’en sait pas assez sur ses besoins réels, on sait juste qu’Odoo Entreprise répond aux besoins actuels, mais pas Odoo Comunity.
Pour le prix, 2000 c’est trop, donc exit Odoo (pas tout de suite, une migration se prépare). Si Dolibarr répond à ses besoins, je pense qu’il doit partir là dessus. C’est stable : j’ai des instances Dolibarr pour des clients et moi-même, et je n’ai jamais eu le moindre pépin (touchons du bois), ni au jour le jour, ni lors des mises à jour. La communauté d’utilisateurs français est grande, le développement est actif, quasi tout est présent d’office, pas d’arnaques du genre « le core est gratuit, mais les plugins sont payants ». Dernier avantage et non des moindres, les instances sont peu chères, je cite : « commencent en dessous de 10€ par mois et des offres à 40-50€ par mois lui semblent bien complètes ». Personnellement je ne vois pas la différence entre une offre à 10 euros et une à 50. J’espère que les deux offrent une sauvegarde qui marche (sinon ce n’est pas une offre). Peut-être la différence se situe dans le délai d’intervention en cas de problème. Il doit exister des offres intermédiaires, genre 25 euros par mois, qui doivent tenir la route (s’il n’y en a pas, je lui fait, je ne suis pas à une instance Dolibarr près), et qui le ferai passer de 2000 euros par an à 300. 1700 euros d'écart, pour beaucoup de gens c'est un mois de salaire.

Reste le gros point de la migration, et là aussi ça dépend de son activité, de son envie, de son temps disponible, et de l’aide que peut apporter l’instanceur (je ne suis pas sûr que ce mot existe, mais tout le monde a compris que je parle de l‘entité qui propose l’instance). Dolibarr a des fonctions d’imports qui sont assez faciles à utiliser, mais faut prendre le temps de bien faire les choses et vérifier que tout est ok à la fin.
De toute façon, faut rester sur Odoo tant que tout n’est pas 100 % ok avec le nouvel ERP, et ça peut prendre du temps, longtemps.

Mon plus long commentaire… mazette, je vais me coucher.

Je n'ai malheureusement pas le plaisir de connaître Chonchon.
A mon prochain retour en France (si un jour ce satané virus le permet), on ira boire un pot ensemble et tu me présenteras ?
S'il est vraiment aussi efficace qu'un collègue faut penser au clonage ou à faire un élevage, il y a des sous à se faire là.

Et il aide vraiment dans les 9 autres % (estimation pifométrique mais sûrement pas très loin de la réalité, en fait ça dépend du-dit collègue) alors que la peluche, elle te laisse dans la merde.

Si ça peut aider…

Quand je bossais en équipe, si un bug me bloquait plus de 5 ou 10 minutes, je demandais au collègue à côté de moi si je pouvais lui expliquer mon problème (et il faisait pareil quand il était bloqué).
Dans 90% des cas, le fait d'expliquer la situation permet de trouver le problème, car ça oblige à prendre un peu de recul, à reformuler les choses pour les rendre compréhensibles à l'interlocuteur.
Dans 9 autres % des cas, c'est le collègue qui trouve, car c'est bien connu qu'il y a toujours plus d'idées dans plusieurs cerveaux que dans un seul.
Dans les 1% restants, on galère à deux.

Un exemple de truc con sur lequel on a galéré : un éditeur (je ne me souviens plus lequel, peut-être gedit) qui faisait la différence entre un espace et la combinaison ALTGR + espace (tapé accidentellement car de mémoire sur le clavier français faut faire ALTGR 5 pour choper l'accolade, et la touche ALTGR a été relachée trop tardivement), et l'interpréteur aussi car il plantait avec erreur de syntaxe, sauf qu'à l'écran, rien ne permettait de faire la différence entre ces deux caractères. J'ai perdu deux heures là dessus pour trouver qu'un espace n'était pas un vrai espace.

Maintenant que je bosse seul, je continue un peu schizophréniquement à appliquer cette méthode : j'imagine un interlocuteur fictif auquel j'explique ce que je veux faire, … et ça marche (dans 90% des cas, ce qui est déjà pas mal).

Ben si, un script php peut très bien tourner tout seul en permanence comme un daemon. Il faut juste qu'il se réveille suivant un événement bien précis.

Il y a quelques années de ça, je me suis amusé à coder un serveur SMTP et POP en PHP. Un listener sur le port 25 et 110 et ça roule. Pas besoin d'apache ou autre intermédiaire. Il tourne en permanence depuis des années sans problème.

Comme tout daemon qui se respecte, faut bien faire attention aux allocations mémoires pour ne pas que la ram se fasse bouffer, ça demande un peu de rigueur au codage, mais ce n'est pas pire qu'avec d'autres langages.

J'avais zappé que tu voulais lancer le daemon avec un autre utilisateur.

Plutôt que d'utiliser sudo (qui n'est pas installé par défaut sous Debian), utilise su :

system("su - www-data -c 'php titi.php < /dev/null > /dev/null 2> /dev/null &'");

A tester…

Debian 6, c'est pas tout jeune, mais ça doit fonctionner comme ça :
Imaginons que ton daemon est le script titi.php qui se trouve dans /home/toto, tu vas devoir créer un petit fichier php nommé toto.php pour gérer le lancement et l'arrêt (tu peux tout mettre dans le même script php, mais bon, pourquoi faire bordélique…)
Tu crées un fichier dans /etc/init.d/toto.sh

#! /bin/sh
set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/toto
DESC="toto daemon"
NAME=toto
DAEMON=/home/toto/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME


case "$1" in
  start)
      echo -n "Starting $DESC: $NAME"
      php /home/toto/toto.php start
      echo "."
      ;;
  stop)
     echo -n "Stopping $DESC: $NAME"
     php /home/toto/toto.php stop
     echo "."
     ;;
  restart|force-reload)
     echo -n "Restarting $DESC: $NAME"
     php /home/toto/toto.php restart
     sleep 1
     echo "."
     ;;
  *)
     echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
     exit 1
     ;;
esac
exit 0

Donc dans toto.php, on a :

<?php

chdir("/home/toto");

$ordre = $argv[1];
$fait = "N";

if ($ordre == "") $ordre = "START";

if (strtoupper($ordre) == "START") {
    echo "\r\nDemarrage du daemon titi.\r\n";
    system("php titi.php < /dev/null > /dev/null 2> /dev/null &");
    $fait = "O";
}

if (strtoupper($ordre) == "STOP") {
    echo "\r\nArret du daemon titi.\r\n";
    // Là à toi de programmer un truc pour que toto.php sache qu'il doive s'arreter 
    $fait = "O";
}

if (strtoupper($ordre) == "RESTART") {
    echo "\r\nRedemarrage du daemon titi.\r\n";
    // Là à toi de programmer un truc pour que toto.php sache qu'il doive s'arreter 
    // puis
    system("php titi.php < /dev/null > /dev/null 2> /dev/null &");
    $fait = "O";
}

if ($fait == "N") {
    // affiche l'aide
    echo "\r\nTITI deamon\r\n\r\n";
    echo "commandes :\r\n";
    echo "  start   : demarre le serveur mail\r\n";
    echo "  stop    : arrete le serveur mail\r\n";
    echo "  restart : arrete puis redemarre le serveur mail\r\n";
    echo "  help    : cette page d'aide\r\n\r\n";
}
?>

Comme dit dans le code. c'est à toi de voir comme informer titi qu'il doit cesser. Ca peut être par plein de moyens (fichier scruté, telnet, …).
Je n'ai pas mis l'option force-reload, tu sauras bien le faire si nécessaire.

Pour qu'il se lance au (re)démarrage de la machine, faut créer un lien symbolique du fichier sh dans /etc/rc2.d :
ln -s /etc/init.d/toto.sh /etc/rc2.d/S99toto

Le S99, c'est pour "Start", et en dernier, ce qui généralement est ok, sauf si tu as besoin qu'il se lance avant d'autres deamons.

Et ce jour la, même les SDF accepteront les dons par le biais de transactions informatisées!

C'est déjà le cas en Chine (si, si, il y a des SDF en Chine, des gens qui font la manche en tout cas, dire s'ils ont un domicile fixe ou pas est plus délicat).
Un QR code, tu scannes avec Wechat ou alipay, tu tapes combien tu veux donner, et hop, le gars reçoit ça sur son compte.

Pour répondre à ta question "qui est responsable dans le coup ?", en premier lieu c'est celui qui a fait les transactions frauduleuses ou l'app vérolée qui a fait ces transactions, mais bon courage pour faire justice…

Passé cette évidence, le deuxième responsable, en tout bien tout honneur et sans vouloir te froisser, c'est toi. Oui, toi qui a cru naîvement que de donner une autorisation de prélèvement à Google (via paypal ou pas) était "safe & secure". Non, ce n'est pas sécurisé, les apps android sur google store ne sont pas "testées et approuvées anti-fraude".

Tu es remboursé par la banque (c'est d'ailleurs une obligation de la banque), donc l'histoire se finit bien, mais à l'avenir, ne plus donner d'autorisation de prélèvement me semble plus sage.

Je comprends bien que la majorité des assos ne roulent pas sur l'or. Mais ce n'est pas forcément très cher. Un petit pro, ce n'est pas Cap gemini non plus, et on sera très loin du coût d'un StopCovid inutile.

Dire combien ça peut coûter, pour l'instant ce n'est pas évident vu que tu as donné un "cahier pas des charges" qui ne laisse qu'entrevoir un échange d'infos via formulaire web. Je suppose que le truc final sera plus étoffé que ça.

Vu que ce n'est plus pressé, sans aller jusqu'au super cahier des charges bien propre, tu peux tranquillement faire le tour des besoins et essayer de formuler ça clairement. Qu'est-ce qui est indispensable ? S'il peut y avoir aussi ça en option, etc. Ca aidera à la fois à faire une estimation du réaliste coût en dév, et pourquoi pas finalement trouver un truc existant qui collerait aux besoins.

Comme déjà répondu sur d'autres sujets assez similaires : c'est du dév.

Tu (l'asso) as un besoin spécifique, qui veut se passer des GAFA, qui veut un truc dont la grammaire colle avec l'univers de l'asso, qui ne soit pas compliqué … sauf si tu trouves quelqu'un qui a déjà développé un truc pour exactement les mêmes besoins et qui est d'accord pour te le filer (parce que libre ou qu'il est sympa)… faut partir sur du dev.

C'est sûr, du dev, ça a un coût, mais pas forcément cher si ce n'est pas compliqué. De plus, si tu veux une appli utilisable sur le web, faut un hébergement, maintenance, backup … il y a sûrement plein de petits pros qui pourront à la fois faire le dev et assurer un contrat de maintenance incluant l'hébergement, les backups, voire le nom de domaine. Si en plus le petit pro a déjà fait de la musique en école de musique et conservatoire, bref un passionné, c'est encore mieux.

Cette appli web peut aussi servir de vitrine sur le web pour l'asso, un peu de communication ne peut pas nuire.
A voir si ton asso a un petit budget à consacrer ou pas. Si pas, faudra se contenter d'à peu près bricolé.

Oui, j'ai sans doute à tort pensé qu'il avait capté un gars du SI connecté en SSH, un humain à l'autre bout du clavier. Si ce qu'il a capté n'est "que" des scripts nécessaires au SI qui font du SSH, alors c'est moins louche.
Mais si un script se connecte en SSH, alors un humain du SI peut aussi le faire. La séparation de ce poste de son réseau domestique reste la seule solution pour avoir l'esprit tranquille.

C’est une question très intéressante car je pense que ça concerne beaucoup de monde et la réponse n’est pas si évidente.

L’employeur (via son service IT) a bien entendu le droit d’accéder au poste, pour y faire de la maintenance, des backups, vérifier la sécurité…
Que ça se fasse par SSH me laisse un peu perplexe. La grande majorité des opérations sont (devraient) être automatisées via des scripts ad hoc. Pour avoir été responsable informatique des nombreuses années, je sais que les opérations manuelles sont très rares, car chronophages. Tu as capté un gars connecté en SSH, tu as bloqué le SSH et le gars a déjà remarqué le truc, c’est louche. Tu lui as demandé ce qu’il faisait ?
L’intégrité du gars ou la confiance qu’on pourrait lui donner ne rentre pas en ligne de compte, personne de la société ne devrait avoir accès au réseau familial.

D’un point de vue technique, mettre le poste en DMZ est la meilleure solution. Ca nécessite un modem/routeur qui dispose de cette fonctionnalité. Je n’ai jamais eu de freebox, mais si le marketing n’a pas encore fait des siennes, le mode invité semble correspondre.

Dans cette situation, si mettre en place une DMZ demande du temps, je la jouerais temporairement idiot du village : le gars dit qu’il n’arrive pas à se connecter en SSH, tu réponds « ah ? Et donc ? ». Tu ne comprends pas ce qu’il demande, il insiste, tu peux même éventuellement t’énerver en disant que c’est son métier de faire en sorte que ça marche, si ça ne marche pas c’est de sa faute, et vous verrez ça la prochaine fois que tu iras sur site (juste avant, tu redémarres SSH, bien sûr).
En attendant, trouve une solution pour isoler ce poste de ton réseau domestique, car c’est hélas la seule solution.

Comme dit plus haut, SSH n’est qu’un moyen parmi plein d ‘autres, donc uniquement bloquer SSH n’est pas satisfaisant. Modifier le VPN pour que tout passe par le VPN n’est pas non plus une solution, vu que le gars se connecte en root et peut donc modifier les paramètres du VPN à sa guise. Les seules solutions sont une DMZ ou un accès internet séparé, car le télétravail fait gagner en frais de carburant et maintenance du véhicule, ou pass navigo, … bien plus que le coût mensuel d’un accès internet ou l’achat d’un modem/routeur adéquat. A méditer.

Bien sûr que c'est le résultat d'une politique de flicage, mais c'est aussi culturel car les chinois en très grande majorité n'en n'ont rien à foutre d'être ainsi pistés.
Leur parler de ce sujet c'est se heurter à un mur d'incompréhension, avec un regard du genre "pourquoi tu perds ton temps sur des sujets aussi futiles".

J'ai eu deux expériences de changement de douchettes PS/2 par des douchettes bluetooth (avec base connectée en USB au PC). La première expérience s'est très bien passée; plusieurs postes côte à côte sans problème, appairage toujours rapide de la douchette à sa base, rapide, bonne portée (une dizaine de m). La deuxième expérience a été catastrophique : autre marque, l'appairage qui marche une fois sur dix, la douchette qui perd la connexion avec la base toutes les 10 minutes, retour aux PS/2.
Moralité : le succès du changement dépend du matos, n'hésite pas à demander deux douchettes en prêt et à tester pendant un moment dans toutes les conditions.

Pour info, dans les deux cas, les code-barres étaient générés en PHP, c'est super facile, et il n'y a pas besoin d'installer quoi que ce soit sur les postes, d'autant que l'intranet local tournait déjà en PHP et incorporait une bonne partie de l'ERP, donc accès direct aux données en PHP. Il y a plein de solutions pour faire des code-barres, mais latex, je n'y aurai pas pensé.

C'est clair qu'en Chine, la question de la vie privée ne s'est pas posée, autre culture autres moeurs. Et les chinois sont déjà pistés de mille et unes autres façons.

Je n'ai pas dit non plus qu'il fallait rendre ça obligatoire en France, ça peut se faire aussi sur le volontariat. Pas de téléphone, tu rentres sans scanner, basta. En Chine c'est obligatoire, mais ça ne veut pas dire que ça ne peut pas fonctionner sur du volontariat. Ca reste toujours bien mieux qu'une appli utilisant bluetooth et GPS, au moins le code serait plus simple, pas d'API google ou autre.

l'appli considère qu'il y a eu contact si vous restez à proximité d'un autre utilisateur de l'appli pendant au moins 15 minutes. On rate donc énormément de contacts. Hier et aujourd'hui, j'ai fait deux fois les courses dans deux grandes surfaces différentes. Au total, j'ai passé moins de 15 minutes dans chacun des grands magasins et pourtant, à plusieurs occasions, la distance de 1m n'a pas été respecté. Mais l'appli n'en garde aucune trace.

Ca m'a l'air bien compliqué tout ça… pourquoi faire simple quand on peut faire compliqué, c'est la devise de la France ?
Puisque je vis en Chine, voilà comment ça a été fait ici : tous les lieux publics ont du afficher deux QR codes que les clients doivent scanner pour rentrer et sortir (donc un QR code pour rentrer, un pour sortir). Il y en a partout, petits magasins, hopitaux, commissariats, bus, metro, … chaque endroit a ses QR codes. Tu ne rentres pas sans scanner.
Pour scanner, on utilise Wechat ou Zhifubao (app alibaba) et peut-être d'autres… tous les chinois et expats ont au moins un compte wechat, zhifubao est également sur quasi 100% des téléphones. On scanne, c'est un lien qui contient l'identifiant du lieu, et l'identifiant du compte wechat. Le serveur a donc toutes les infos nécessaires :
ID de la personne, lieu concerné, date et heure d'entrée et de sortie dans le lieu.

Avec ça, si un cas de covid est découvert, il est facile de retracer tous les lieux publics fréquentés et toutes les personnes éventuellement croisées (donc à faire tester).

Pas de bluetooth, pas de GPS, ça fonctionne sur android et iphone sans problème.
En France on n'a pas wechat ou équivalent, donc faire une appli dédiée, pourquoi pas. Mais se baser sur du bluetooth et du GPS, c'est se créer des emmerdes. Une appli simple qui demande de s'identifier une seule fois, puis scanne des QR codes pour envoyer à un serveur le couple ID/lieu, ça aurait été beaucoup plus simple, code facilement auditable, pas d'API proprio, … mais non, on a préféré faire compliqué au lieu de s'inspirer de ce qui se fait ailleurs, comme d'hab.

A HT constante, oui, le courant (nbr d'électrons) cathodique sera plus faible. Sauf que la tension n'est pas vraiment fixe. A cathode froide, la tension (haute) va encore monter pour essayer d'atteindre la stabilité du circuit, qui est fonction de l'impédance des tubes et du transfo de sortie. Bref, même à froid il y aura des électrons pour se faire la malle, ce ne sera pas vraiment "négligeable".
La HT est filtrée, mais les condos ne sont pas énormes, dont la tension peut varier assez facilement d'un 500V en pic à un petit 250V en pleine charge (c'est le fameux effet de pompage recherché par certains guitaristes).

Normalement, le filament de chauffage des tubes (du 6,3V alternatif) sert à chauffer la cathode afin que les électrons quittent plus facilement la cathode, sans la bousiller.

Sans signal (à amplifier) et par la présence de la haute tension entre la cathode et l'anode, il y a déjà un courant entre la cathode et l'anode (il s'appelle le bias). Ce courant varie ensuite en fonction de la tension de la grille (le signal).

Donc tu vois que, si tu appliques la HT, il va déjà y avoir des électrons qui vont se barrer de la cathode. Or s'ils se barrent quand la cathode est froide, pas bon, usure…

Donc coupe la HT, allume les filaments de préchauffage, attends 30s, puis allume la HT. Comme ça pas de problème.

Pour être plus précis, c'est fonction de la valeur de la HT par rapport à la tension max de fonctionnement du tube, selon qu'il y ait de la marge ou pas.

Dans ton cas, je suppose que tu parles d'ampli guitare. Les tubes sont utilisés quasiment à leur Vmax (et même volontairement au dessus pour certains designs). Du coup, appliquer la HT à froid va avoir plusieurs conséquences, principalement :
- travail en phase non-stabilisée ; le rendu sonore sera étrange et incontrôlable avant stabilisation thermique.
- usure prématurée de la cathode. Ce n'est pas instantané, mais arracher de force des électrons à pleine Vmax sur une cathode froide, il y a des morceaux de traitement de surface qui vont partir avec.
Et effet, là où 300 ou 350V suffiraient pour sortir la puissance (débit correct d'électrons sortis d'une cathode chaude), il en faudra 500V pour les sortir d'une cathode froide, avec risque de claquage des condos s'ils sont un peu vieux et limites.

Bref, si tu fais l'essai, il y a de grande chance pour que tout se passe bien et que l'ampli se stabilise tranquillement. Mais les gratteux et bassistes soucieux de leur matos (c'est pas donné ces bêtes là) et qui essaient d'éviter la douloureuse de l'atelier de réparation, ils font gaffe et laissent chauffer tranquillement avant d'envoyer la purée.

Tu t'occuperas des jours / mois / années de marketing, et sur tes deniers personnels, n'est-ce pas ?

Sur le fond, les employés de Cloudflare n'ont sans doute pas eu leur mot à dire, dans ce genre de grosse boite les décisions ne sont majoritairement pas prises par des gens de la technique. D'après Wikipedia, Cloudflare est une boite "qui propose un réseau de distribution de contenu, des services de sécurité Internet et des services distribués de serveur de noms de domaine". Je ne doute pas un instant qu'ils aient les compétences en interne et l'infra pour le faire. Ca a tout l'air d'être une décision politique interne, aussi illogique (pour le dev que je suis) ou logique (pour d'autres, y compris les décideurs de la boite en question) qu'elle puisse être.

Ton ton condescendant - ou agressif selon ton propre jugement -, je m'en contrefous. Je ne t'embaucherais pas en tant que dev, non pas parce que tu es antipathique, mais parce que visiblement tu ne connais rien sur l'aspect technique en question, et encore moins sur le fonctionnement interne des grosses boites.

Merci de mettre en doute mes compétences, après tout, on ne se connait pas, hein.
Si le sujet parlait de pêche à la ligne, je ne serais pas intervenu, car la pêche à la ligne, je n'y connais effectivement rien.
Tu me permettras donc, contre ton avis éclairé, de maintenir qu'un captcha basique, c'est une demi-heure de dev. Un captcha top-moumoute, deux jours max. Je ne compte bien entendu pas le marketing, chacun son métier.

Maintenant, Cloudflare, ce n'est pas un petit siteweb perso dans un coin, s'il n'ont pas l'infra ou les compétences, c'est bien dommage. Ils ont fait le choix d'externaliser, c'est leur choix, mais par expérience personnelle (que tu peux à nouveau mettre en doute gratuitement), l'externalisation est souvent un mauvais choix fait pour de mauvaises raisons (pour citer la principale : ne pas prendre la responsabilité du truc, se couvrir en cas de problème genre "ce nest pas moi, c'est le prestataire qui a merdé").

D'un point de vue développeur, ce que je ne comprends pas c'est pourquoi ils n'ont pas créé leur propre captcha.
Ce n'est quand même pas difficile à développer. En une demi-heure tu as un truc qui tient la route.
S'ils veulent la rolls des captcha, alors ils mettent un gars dessus pendant deux jours et basta, et ça fait une dépendance en moins.

J'en ai déjà brièvement parlé là (et même réussi à choper un "inutile", haha) : https://linuxfr.org/users/antistress/liens/pour-ceux-celles-qui-vantaient-l-efficacite-de-la-gestion-de-la-crise-par-les-dictatures-chine#comment-1802650

Ca marche aussi pour les déconfinés. ；）
Je suis en Chine et je pense que je vais m'en donner à coeur-joie maintenant que tous les grillages ont été levés. J'avais remarqué de grosses lacunes dans openstreetmap sur mon quartier et les quartiers voisins.
Je me demande juste s'il faut écrire les éléments en caractères chinois uniquement ou aussi en américanisant/anglicisant les noms (par exemple 东风路 en Dongfeng Road).