xulops a écrit 303 commentaires

Moi à ta place j'irais faire un tour dans le bios (ou ce qui en tient lieu) histoire de voir s'il n'y a pas un truc du genre "économie d'énergie" qui désactiverait la carte graphique si pas d'écran branché au boot. Sait-on jamais…

En effet, dans 100 ans il sera mort, et moi aussi (et même bien avant). Du coup la question n'est sans doute pas destinée à nous-même, mais plutôt à nos enfants, … enfin, aux vôtres, puisque moi je m'en fous, je n'en ai pas.

Mais la question est intéressante et la réponse est fortement lié à l'évolution de la population.
S'il n'y a que quelques centaines de milliers de gens sur Terre, sauf annihilation totale à coup de bombes nucléaires, peu importe combien ils consomment, polluent, … il y aura toujours un endroit vivable pour eux.

A 10 milliards sur notre caillou, c'est une autre histoire. Alimenter tout le monde est actuellement un jeu d'équilibres que le réchauffement climatique, entre autres, peut (va) mettre à mal.
Bref, on est trop nombreux sur Terre, donc ça va forcément merder à un moment où à un autre.

Une petite note d'optimisme : à voir si la natalité ne baissera pas naturellement dans les décennies à venir, comme c'est le cas dans beaucoup de pays "développés", sans aller jusqu'à des mesures draconiennes comme le fût la politique de l'enfant unique en Chine.

Petit aparté sur le cas de la Chine : la politique de l'enfant unique est révolue puisque maintenant ils peuvent avoir 2 gosses gratos, et même davantage si les parents sont riches, car c'est le système inverse des allocations familiales françaises : plus tu as de gosses, plus tu payes. Deux, c'est gratos, mais beaucoup de familles se limitent à un gosse (le minimum pour sauvegarder la face) car élever un gosse coûte cher en Chine.

Tu as raison.
On ne parlait juste pas tout à fait de la même chose, je voyais ça pour un usage proche de celui de la Suède, à savoir s'identifier sur des sites étatiques ou assimilés, là où s'identifier a vraiment un intérêt, pas pour les sites lambda comme linuxfr.
Mais il ne faut pas se leurrer, quand cette identification sera mise en place (et elle le sera, ce n'est qu'une question de temps), il y aura forcément ensuite une loi qui sera pondue pour que ce soit obligatoire, y compris sur les sites lambda, au nom de la lutte contre le terrorisme informatique (l'excuse qui fait tout passer).
Il y aura quelques avantages, par exemple il faudra assumer ses propos sur les forums et autres, fini de se cacher derrière un pseudo, mais il y aura aussi risque de dérives de l'état.
Donc tes craintes sont fondées, non pas sur l'usage initial, mais sur l'usage détourné à long terme, compte tenu de la nature des hommes de pouvoir. La France n'est pas la Suède, la transparence n'est pas dans nos moeurs.
C'est l'histoire du couteau qui sert à couper la nourriture, ou à tuer quelqu'un. L'outil peut être utilisé à bon escient, ou pas.

Non, avec un truc type GPG, ce n'est pas le cas. Chaque site contient ses utilisateurs, mais personne n'a la liste complète.

Oui, si le but est de s'authentifier. Non, si le but est de s'identifier. Ce sont deux besoins différents.

Le croisement de fichier fait peur. C'est à double tranchant. L'état sera bien plus efficace pour traquer les abus, les personnes en difficulté et les opposants politiques.

Ca dépend… de l'usage qui en est fait; sans doute.
En Suède ça se passe bien, c'est efficace (l'administration suédoise est globalement largement plus efficace que l'administration française). Que les abus (des politiques surtout) et personnes en difficulté soient traqués plus efficacement me semble être plus une qualité qu'un défaut. Pour les opposants politiques… heu, je ne vois pas ce qui pourraient être fait de plus que ce qui se fait déjà (les RG ont déjà des dossiers bien remplis), et là aussi il n'y a pas de cas en Suède venant conforter cette idée.

Le sujet est "Authentification et identité numérique…", donc c'est un peu le but d'avoir un ID unique qui soit facile à utiliser pour s'identifier sur les sites sur lesquels une identification est nécessaire.

Pour le fichage, je ne vois pas ce que ça ajoute de plus que ce que l'état connait déjà. Tu as d'ailleurs déjà quelques ID uniques (numéro de sécu, CNI, numéro de passeport…), et des moyens de t'identifier (france connect et consorts), c'est juste que c'est un peu le bordel, donc pas simple d'utilisation.

C'est un sujet déjà maintes fois abordé, et le résultat est que la France fera comme elle fait toujours : filer le marché juteux (sur le dos des contribuables) aux copains des grosses SS2I avec un résultat à la hauteur de l'appli stopCovid, c'est à dire proche du néant.

Il ne faudrait surtout pas pour une fois s'inspirer de ce qui se fait ailleurs et qui fonctionne.

Par exemple en Suède, il existe depuis belles lurettes une infrastructure nommée BankID qui répond aux besoins. Voila comment ça fonctionne :

En premier, il faut un personummer : numéro personnel, genre de numéro de carte d'identité qui fait 12 chiffres (facile à retenir puisque 8 chiffres sont la date de naissance, et les 4 autres un numéro séquentiel des demandes pour cette date). En France on a le numéro de sécu qui s'y rapproche. En Suède, tout le monde à un personummer, et donc une carte d'identité suédoise, y compris les étrangers qui s'y installe (avoir une carte d'identité suédoise ne veut pas dire qu'on est de nationalité suédoise).

Ensuite il faut une application sur smartphone, application a un code secret pour se lancer (6 chiffres).

Si on veut s'authentifier sur un site quelconque (sa banque, les impôts, aides sociales, payer un amende, rechercher un job sur le site du pole emploi, …), le cheminement est le suivant :
- sur le site, je tape mon personnummer (ce n'est pas un secret).
- le site contacte BankID (intermédiaire de confiance) et me dit de lancer l'appli BankID sur mon smartphone.
- je lance bankID sur le smartphone, tape mon code secret (6 chiffres), et l'appli m'indique que le site xxx que je consulte veut que je m'authentifie.
- je dis ok. C'est terminé.

Le site en question ne connait que mon personummer et BankID lui a confirmé que c'est bien moi.
Le tiers de confiance sait que je me suis authentifié sur tel ou tel site. Ca peut être vu comme un problème de confidentialité, mais c'est censé être géré par l'état, qui peut déjà consulter les logs des FAI, donc bon…

Paraitrait-il que l'appli BankID nécessite les API google. Je n'ai pas vérifié, et s'en inspirer ne veut pas dire faire exactement pareil. Il y a moyen de faire un truc propre et léger.

J'entends déjà hurler les "c'est cool ton truc, mais je n'ai pas de smartphone, comment je fais ?". Il existe aussi des genres de mini-calculettes qui demande un code pin (secret, initialisé au départ) qui génèrent des nombres uniques et temporaires (jetons), c'est également ce qui est utilisé en Suède, fournie gratuitement et qui tient dans la paume de la main. C'est principalement utilisé pour valider les paiements en ligne.

Mais mon côté pessimiste me fait dire qu'on va réinventer la chose, pour très cher et en moins bien. La french touch quoi.
En cadeau : ma main velue avec une calculette fournie par Sewdbank.

C'est super de l'avoir fait, et de partager.

J'ai une question à propos de la killer feature, si chacun peut partager son écran et que ça s'ouvre automatiquement sur tous les écrans, est-ce que ce n'est pas un peu le bordel avec une classe ou un groupe, disons, un peu dissipé ou espiègle ?

Pour de la formation, dans l'idéal il faudrait que le prof / formateur puisse choisir qui partage son écran avec tout le monde à un moment précis. Faudrait donc en quelque sorte une appli maître qui commande les applis des postes. Mais ton besoin est peut-être différent.

Pour le front office (on ne parle que ce celui-là, puis que le backoffice n'est pas multilingue, mais c'est pareil), faut distinguer le contenu statique du contenu dynamique.

Le contenu statique est créé / ajouté par le développeur au moment où il code le truc. S'il devait faire des aller-retours entre son code et la BDD à chaque fois qu'il doit ajouter un libellé, il va vite péter un câble. Donc la partie statique est presque toujours en fichiers qui n'évoluent pratiquement plus une fois le dev terminé. Sur la façon de stocker en fichier, il y a plusieurs écoles.

Le contenu dynamique, il est créé / ajouté par les utilisateurs du site, ou par des personnes en charge de la rédaction, bref pas par des devs, et ils ne savent bien souvent même pas comment sont stockées les données. Dans la grande majorité des cas, c'est stocké en base, avec un index sur la langue du contenu.

Ce sont surtout des considérations pratiques : vitesse/confort de dev pour le statique, facilité de récupérer directement le contenu dans la bonne langue en dynamique.

Maintenant, une base de données, ce n'est qu'un ensemble de fichiers, dans un format particulier, que va lire un moteur de requêtes.
Le meilleur exemple (le plus simple), c'est un fichier VSAM sur AS/400, le fichier peut contenir plusieurs membres, chaque membre est comme un tableau avec colonnes de largeur prédéterminée, par exemple ID de la colonne 1 à 5, langue de la colonne 6 à 14, titre de la colonne 15 à 89, etc.
A côté de ça, tu as des petits fichiers de définition d'index que le moteur DB2 utilise pour retrouver très rapidement que la ligne avec l'id 34564 est à la 23464 ligne du ficher. Un seek, un read, et c'est fini (je simplifie un peu quand même).
Bref, si tu stockes en fichier, tu as un code pour lire le fichier, en extraire la valeur (souvent un fichier de type cle/valeur). Si tu stockes en base, c'est le moteur qui fait le boulot.

Niveau performance, tant que le contenu statique ne fait pas des Mo, la solution fichier est la meilleure car le fichier est lu une fois et reste en cache tout le temps. Si c'est stocké en base, il est possible que le moteur dégage la table en question du cache si d'autres requêtes bien bourrines bouffe la ram jusqu'au paramètre de cache défini. Du coup, le statique en fichiers gagne sûrement un peu niveau IO.
Pour le dynamique, c'est censé gonfler dans le temps, c'est bien en base.

Les gens ne répondent généralement pas à ce genre de question, va savoir pourquoi … je vais essayer.

Ce que j'ai développé est assez complet et surtout très adapté aux besoins (c'est l'un des buts de le développer soi-même). Donc te donner un prix ne serait utile que si je te donne aussi le descriptif complet des fonctionnalités ce qui serait fastidieux (par exemple chaque tablette peut contrôler le son diffusé dans le resto, changer de morceaux, volume…).
On va donc faire plus simple, en ne prenant qu'un (déjà gros) morceau plus facile à décrire : la saisie de commande, son traitement et son encaissement.

Donc en gros :
- une interface web
- responsive (usage principal sur tablettes, mais aussi smartphone à l'occasion) et prévue pour un usage tactile,
- Une page principale pour la saisie qui affiche les produits par catégories (plats principaux, boissons, desserts), on change de catégorie en cliquant sur un bouton, ça change la liste des produits. Doit figurer la liste des produits de la commande en cours avec prix et quantités, et les boutons qui vont bien pour les modes de paiement (en espèce, Weixin (Wechat) ou Zhifubao (alibaba), le numéro de commande, l'origine de la commande (en magasin ou par internet, principalement Meituan et eleme en Chine), mise en attente du paiement (il y a des gens qui paient à la commande, d'autres après avoir mangé), et sur le lien de la deuxième page, le nombre de produits à préparer dans la cuisine concernée.
- une seconde page avec la liste des commandes en cours pour la cuisine concernées. Un bouton pour dire que c'est donné au client, les autres lignes sont affichées en petits et en gris mais permettent de faire l'encaissement si besoin (des clients commandent à une cuisine, mais paient à l'autre, ça arrive).
- le tout en chinois, mais c'est anecdotique, quoique pratique puisque le texte est souvent plus court.

S'il ne faut faire que cela, avec dans la partie administration la gestion des catégories et des articles (ordre d'affichage, prix, actif), le tarif que je demanderais se situerait entre 2000 euros et 3000 euros.
Certains pourraient trouver ça cher : déjà je ne prétends pas être le moins cher du marché, la qualité et le bon relationnel se paie aussi, puis il y a du boulot à faire quand même, et ils sont libres de prendre un autre prestataire moins cher.
Certains pourraient trouver que ce n'est pas cher du tout : j'ai l'habitude de développer des trucs comme ça, c'est du boulot mais ça va finalement assez vite, et je vis dans un pays où le coût de la vie est faible.
Chacun voit midi à sa porte.

Je tente d'insérer une image de la page principale :

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.