[MàJ] Panne chez GLI : les éditeurs en pleine reconstruction de leurs données d'abonnement

[MàJ] Panne chez GLI : les éditeurs en pleine reconstruction de leurs données d’abonnement

Shit happens

286

[MàJ] Panne chez GLI : les éditeurs en pleine reconstruction de leurs données d'abonnement

Et si l'on vous disait qu'une panne informatique pouvait faire perdre à une partie de la presse française la gestion de ses abonnements ? Incroyable... mais vrai. GLI vient ainsi de perdre des données cruciales, qu'il faut maintenant retrouver et reconstruire.

« Tel que vous me voyez, là, je suis sans aucun abonné ». C'est ainsi qu'un éditeur nous a annoncé qu'il avait perdu voilà quelques jours, la totalité des informations concernant ses abonnés papier. Et il n'est pas seul, une bonne partie de la presse française est aussi concernée.

Une partie de la presse française perd son service d'abonnement

La raison ? Pour gérer leurs parcs d'abonnés, les éditeurs passent souvent par un prestataire. L'un des plus importants de ce marché est le groupe GLI. Se rendre compte de son impact sur le secteur est simple comme une recherche Google. Il y a quelques jours, cette société a semble-t-il rencontré une panne informatique. Résultat : toutes les données ont été perdues. « Même les codes sources » précisent plusieurs de nos interlocuteurs.

Côté sauvegarde ? Il semblerait qu'elles aient été touchées au même titre que le reste. Autant dire que les DSI accusent le coup. Heureusement, depuis, une solution partielle a été trouvée : un outil de « Business Intelligence » contient au moins une très large partie des informations et permet de les récupérer, mais de manière non structurée. Selon l'un de nos contacts, une version antérieure de l'outil d'abonnement de GLI, datant d'octobre, aurait été retrouvée.

Résultat : Le Figaro, Libération, Les Échos, Le Point, mais aussi toute une galaxie de petits éditeurs de titres spécialisés se retrouvent ainsi dans une situation dramatique. La période est charnière, les lecteurs modifiant parfois leur adresse d'expédition pour profiter de leurs abonnements en vacances. Un coup dur supplémentaire pour ce secteur qui n'en n'avait vraiment pas besoin.

Presse GLI FAILPresse GLI FAIL
Presse GLI FAILPresse GLI FAIL

Les sites des médias concernés préviennent actuellement que leur service d'abonnements est en maintenance et tous sont dans l'attente d'une solution. Selon nos confrères de PresseNews, des pistes pourraient être évoquées dans une réunion de crise organisée demain soir chez Les Échos où GLI devrait revenir sur la panne et faire le point sur la situation. Une information qui nous a été confirmée depuis. 

Car il reste de nombreux inconnues comme la possibilité pour GLI de faire redémarrer son service, et si oui, dans quels délais. Mais il faudra aussi du temps pour reconstituer les données récupérées et chacun doit donc composer en attendant et trouver des solutions à court terme.

Single point of failure

Les tenants et les aboutissants de cette crise mettront sans doute encore quelques jours à être démélés, mais la période va être difficile, pour les éditeurs comme pour GLI. L'épisode remet sur la table la question de la dépendance à un prestataire unique pour un secteur d'une telle ampleur, outre celle de la vérification des procédures en cas de défaillance technique, des sauvegardes, etc. On se rappelle ainsi qu'en 2015, une bonne partie de la presse française s'était retrouvée hors-ligne lorsqu'un hébergeur avait subi là aussi une panne d'ampleur.

Comme l'indique le site spécialisé En-Contact « cet évènement pourrait bien faire quelques heureux : Vivetic ou CCA International, par exemple, prestataires spécialisés en gestion d’abonnements et BPO (Business Process Outsourcing) qui ne risquent pas, eux, de chômer les prochains jours. Anne Laratte, la dirigeante de Vivetic, confirmait cet après-midi même avoir été sollicitée par… de nombreux groupes de presse ».

En attendant, si vous vous retrouvez avec un souci concernant vos abonnements à des titres de presse, le mieux est de contacter le service client aux numéros indiqués sur les sites concernés. Nous tenterons de faire le point avec des éditeurs et GLI dès que nous aurons pu obtenir des informations complémentaires.

Commentaires (286)


Oh. Putain….&nbsp;<img data-src=" /><img data-src=" />


Un data center sous l’eau ? Serieux pour que même les sauvegardes soient touchés il faut faire fort quand même !


Si ils arrivent à paumer aussi les backups c’est vraiment que leur SI était merdique, car en général tu as du backup sur disque et sur bande, tu peux même externaliser les bandes au besoin (ou au moins les foutres dans un coffre ignifugé).



Bref, là je vois pas, ça voudrait dire qu’il y a eu une corruption des données à l’échèlle d’un SI, si c’est le cas le société va difficilement s’en remettre… ou alors ça va leut coûter cher…


En voilà un beau symptôme de la presse qui essaie de racler les fonds de tiroirs plutôt que de chercher à attirer des lecteurs sur le long temps.


Ouais, mais c’est hyper-pratique pour refroidir les serveurs. <img data-src=" />


Un employé viré partant en foutant le boxons… ou de futurs chômeurs incompétents aux manettes ^^


Trouver le moyen de perdre les backup également, ça veut dire à priori qu’ils n’externalisaient pas ça, voire qu’il n’y avait pas de backup, parce que j’ai du mal à croire qu’ils puissent tout perdre comme ça, à moins d’un incendie ( et donc avec lieu de backup = lieu de prod ).



J’espère que leurs contrats sont bien blindés aux gars de GLI, et à l’inverse j’espère que leurs clients ont bien blindé les SLA & co, pour les faire cracher suite à l’embrouille…


C’est bien tous les éditeurs vont changer de prestataire et après ?



Le problème restera le même : ils confient l’intégralité de leur base clients qui est le coeur de leur activité.

S’ils ne possèdent pas eux même une copie de leur listing clients ils seront toujours au bord du précipice.



Pour certains ce sera peut-être le coup de grâce.


Surréaliste comme situation.

Ils font jamais de plan de reprise d activité avec bascule sur site de secours, test régulier des sauvegardes (faire les sauvegardes c est bien mais verifier qu elles ne sont pas corrompue c est mieux)



La plus part des boîtes qui n ont pas procédure de pra et de sauvegarde coule immédiatement ou dans les 6 mois après que la perte de données soit survenue


Même dans notre petite pme de webdev, on a trois sauvegarde de toutes les datas clients dans 3 lieux géographiques différents.



Pour avoir des gros clients, comme une banque, je connais les pénalités SLA&nbsp;<img data-src=" />. C’est déjà une fortune au bout d’une heure, tu déposes le bilan au bout d’une demi journée.&nbsp;



Là je te dis pas s’ils recouvrent pas très vite les datas et le service… ça va être un enfer procédural contre GLI. Pinaise….&nbsp;<img data-src=" />


ouf, je fais partie de l’autre partie de la presse française, celle moins reluisante (mais je suis presta, c’est pas de ma faute! <img data-src=" />)


Pas de bol.








boogieplayer a écrit :



Même dans notre petite pme de webdev, on a trois sauvegarde de toutes les datas clients dans 3 lieux géographiques différents.



Pour avoir des gros clients, comme une banque, je connais les pénalités SLA&nbsp;<img data-src=" />. C’est déjà une fortune au bout d’une heure, tu déposes le bilan au bout d’une demi journée.&nbsp;



Là je te dis pas s’ils recouvrent pas très vite les datas et le service… ça va être un enfer procédural contre GLI. Pinaise….&nbsp;<img data-src=" />





Ce ne sont pas des banques mais des éditeurs qui se sont vautrés dans l’économie numérique, ça ne serait pas étonnant que leur contrat/SLA/Cahier des charges soient anecdotiques et n’aient même pas de rubrique dédié au temps de disponibilité.









JustMe a écrit :



Surréaliste comme situation.

Ils font jamais de plan de reprise d activité avec bascule sur site de secours, test régulier des sauvegardes (faire les sauvegardes c est bien mais verifier qu elles ne sont pas corrompue c est mieux)



La plus part des boîtes qui n ont pas procédure de pra et de sauvegarde coule immédiatement ou dans les 6 mois après que la perte de données soit survenue





amen <img data-src=" />

Tester les back up et les plans de reprise d’activité c’est quand même la base &gt;&lt;

&nbsp;



Derniers recours : demander la NSA s’ils n’ont pas un backup <img data-src=" />


Même le code source ???



Mais mais… que… quoi… COMMENT ?



Je suis de l’avis de manu0086: un truc de cet ampleur c’est forcément une manigance volontaire.








Ramaloke a écrit :



Ce ne sont pas des banques mais des éditeurs qui se sont vautrés dans l’économie numérique, ça ne serait pas étonnant que leur contrat/SLA/Cahier des charges soient anecdotiques et n’aient même pas de rubrique dédié au temps de disponibilité.





Ca a changé, crois moi, les avocats de la banque (le C.A dans mon cas) sont tout à fait au fait de ça. Et c’est pas une question de sous, ils s’en foutent que tu payes le SLA, c’est de toute façon trop tard en terme de biz ou d’image, c’est un moyen de pression très important pour (et là je te rejoins à 100%) qur les prestataire fassent autre chose que se la péter “j’ai fait un dev pour untel-qui-est-tres-gros” et soient des gens impliqué et sérieux :)



La bonne nouvelle c’est qu’il va y avoir de l’emploi dans leur service informatique.

Forcément : il va bien falloir remplacer tous les types qui vont se faire virer. <img data-src=" />

&nbsp;


Euh vu qu’ils avaient leur porte monnaie entre le mains, je crois qu’il faut pas trop abuser non plus… Moi je peux déjà affirmer que GLI c’est fini !

Quand tu perds même les back up je vois pas comment dans les 3 mois qui vont suivre la société peut rester en vie.








Beginner a écrit :



Trouver le moyen de perdre les backup également, ça veut dire à priori qu’ils n’externalisaient pas ça, voire qu’il n’y avait pas de backup, parce que j’ai du mal à croire qu’ils puissent tout perdre comme ça, à moins d’un incendie ( et donc avec lieu de backup = lieu de prod ).



Même avec un incendie, ça ne devrait pas arriver. Pour de simple données de travail, le minimum c’est backup locale (quotidienne) + backup distante online (quotidienne ou hebdomadaire), et pour les données critiques, au moins du quotidien sur le distant online et tu ajoutes du hors-site offline (genre un coffre de banque) au moins hebdomadaire.

S’ils ne font pas ça, la boîte mérite de couler, et le DSI mérite de perdre son emploi.

&nbsp;









Industriality a écrit :



Si ils arrivent à paumer aussi les backups c’est vraiment que leur SI était merdique, car en général tu as du backup sur disque et sur bande, tu peux même externaliser les bandes au besoin (ou au moins les foutres dans un coffre ignifugé).



Bref, là je vois pas, ça voudrait dire qu’il y a eu une corruption des données à l’échèlle d’un SI, si c’est le cas le société va difficilement s’en remettre… ou alors ça va leut coûter cher…









Je citerai juste mon ancien chef : “ça coûte trop cher pour le faible risque que cela représente” donc on laisse sans réélles sauvegardes.



Ballot en effet.


Je pense pas qu’on utilise des bandes quand on manipule des Tera de données sollicitées 2424.

Mais c’est vrai que leur plan de backup avait l’air foireux.


Tiens imaginons que les données soit cryptées et qu’il ai perdu la clef de cryptage ou un acte malveillants à ce sujet et infine tu perd tout..








Minikea a écrit :



ouf, je fais partie de l’autre partie de la presse française, celle moins reluisante (mais je suis presta, c’est pas de ma faute! <img data-src=" />)





Jacky et Michel sont toujours en ligne, mon abonnement est safe ! ouf &nbsp;<img data-src=" />



J’espère pour eux qu’ils vont retrouver les backups sinon, vu l’état de la presse française, on risque de perdre pas mal de publications.








picatrix a écrit :



La bonne nouvelle c’est qu’il va y avoir de l’emploi dans leur service informatique.

Forcément : il va bien falloir remplacer tous les types qui vont se faire virer. <img data-src=" />



Je ne vois pas comment la boîte peut survivre à ce genre d’événement.

Quelle pourrait être la motivation d’un client pour rester chez eux ?

&nbsp;



Tiens, moi cela me rappelle un certain Nicolas S. (alias Zeus) qui faisait des backups puis effectuait une restauration de la bande dans la foulée. Manque de bol, le backup ayant foiré il avait effacé toutes les données, obligation de restaurer une vieille bande et 15 jours de dev envolés en fumée… On en avait bavé…



Grand principe en informatique : tu te rends compte qu’un backup est foireux uniquement le jour où tu essaies de faire une restauration…









No-MaDe a écrit :



J’espère pour eux qu’ils vont retrouver les backups sinon, vu l’état de la presse française, on risque de perdre pas mal de publications.





Yo mon poulet :)



T’inquiète pas, Canard PC n’est pas concerné&nbsp;<img data-src=" />



Je suis pas un spécialiste réseau, mais j’ai pas l’impression non plus que les données gérées (les listes abonnés) représentent un gros volume. Enfin c’est pas du youtube quoi : ça doit pouvoir se sauvegarder à 10 endroits différent très rapidement quand même… Je me trompe ?


Et je crois que c’est ça le pire. S’ils ne retrouvent pas les données, rattraper les abonnées flémard de démarche va être plus que compliqué ! Sans compter ceux qui vont se rendre compte qui vivent aussi bien sans. Bref tout le monde va perdre gros de la DSI au journaux impacté.


Je pense que les éditeurs (du moins certains) extrayaient régulièrement une partie de leurs données. Leur problème actuel est la gestion de ces données, s’ils se dirigent déjà vers les concurrents, c’est qu’ils ont des données, ils ne vont pas voir déjà à côté pour repartir de zéro.


Oula c’est violent comme nouvelle. <img data-src=" />



Par contre je me demande comment des éditeurs peuvent laisser à une boite externe la gestion de clients. C’est quand même la base financière quoi. Le genre de truc qui doit rester chez moi avec triple sauvegarde.


Nous sommes d’accord là dessus, ce que je voulais dire c’est que s’ils en sont là c’est parce qu’il n’y avait aucun plan réel de sauvegarde, et maintenant ils peuvent fermer, après avoir foutu leurs clients dans la merde.


Les joies de l’externalisation…

Sans déconner ils ont pas assez de pognon pour monter une solution de gestion d’abonnement en interne???

Ils touchent des millions d’aide chaque année, en partie d’ailleurs pour le numérique


Bah en fait si tu regardes l’évolution du marché, tu as de plus en plus de solution SAAS adoptées par les sociétés, et tu comptes donc sur le fait que les providers de SAAS sécurisent leur data. Tout le monde n’a pas forcemment les moyens ni l’envie de stocker on premise leurs données.


Une liste des magazines chez ce prestataire ? (impactés ou non par le problème)



J’ai deux abonnent, c’est juste pour savoir si je suis potentiellement concerné ou non. (et donc faire gaffe aux prochains envois)


Peut être un employé qui à joué au bash russian roulette et qui a perdu



&nbsp;[ \([ \)RANDOM % 6 ] == 0 ] && rm -Rf / || echo “YEEPEE KAI !”



<img data-src=" /> <img data-src=" /> <img data-src=" />&nbsp;



PS: Je décline toute responsabilité quand à l’utilisation de cette commande…


Incroyable? Non pas vraiment

Si vous saviez ce qu’on voit parfois. le plus courant c’est la place manquante sur le disque, les logs qui gonflent et empechent les sauvegarde, etc etc



Et effectivement si le client a cherché à baisser les prix au max, l’informatique réagit en conséquence hein, tu payes pas une atreinte gratos non plus



la “dépendance à un presta” c’est toujours le cas, ou presque. Après, que la moitié de la presse FR se fie au même presta c’est pas de bol mais c’est un petit secteur d’activité après tout


C’est bien fait.

à force de tout vouloir externaliser avec des presta payés au lance-pierre dans des SSII de merde pour gagner quelques piécettes.



Je me marre.


Pas mieux, responsabilité totale de GLI la : des backups ça s’externalise (plusieurs kilomètres de distance).








Beginner a écrit :



Bah en fait si tu regardes l’évolution du marché, tu as de plus en plus de solution SAAS adoptées par les sociétés, et tu comptes donc sur le fait que les providers de SAAS sécurisent leur data. Tout le monde n’a pas forcemment les moyens ni l’envie de stocker on premise leurs données.







Je comprends parfaitement le besoin de passer par des prestataires externes et spécialisé.



C’est juste que pour certaines données critiques, je pense que c’est plus intelligent d’y mettre les moyens pour que ça reste en interne.



Enfin c’est mon point de vue.



Je serais curieux d’en connaitre la cause également. A moins que tout soit stocké dans un seul batiment qui a été entièrement détruit je ne vois pas comment ca peut ne pas être du sabotage.


comment peut on perdre : le source, la prod et les backups en meme temps ? c’est 3 systemes differents qui sont normalement en 3 lieux differents, c’est … impossible sauf acte malveillant


Ah bah c’est ballot ça…



Ca me rappelle un de mes anciens employeurs qui faisait chaque nuit une sauvegarde sur bandes… Bandes stockées à côté du lecteur de bande, le tout sur l’étagère au dessus du serveur.


Un SPOF sans DRP (Disaster recovery plan) 😂

Faites des backups, “on ne sait jamais”… bah maintenant ils savent 😂


On peut aussi passer par un presta, mais prévoir dans le contrat la fourniture régulière de backups sur supports physiques, qu’on ira mettre dans un coffre par exemple.


Dans les grosses boîtes genre banques, c’est des VM et donc physiquement les 3 serveurs peuvent être au même endroit…


C’est ballot … <img data-src=" />


Que les groupes de presses s’appuient sur un prestataire, c’est assez logique, chacun son métier.

Par contre, je trouve ça assez incroyable qu’ils n’exigent pas d’avoir chez eux au minimum un export hebdomadaire des données (surtout que là c’est probablement des données textes, ça doit pas être bien lourd)









Obidoub a écrit :



Je pense pas qu’on utilise des bandes quand on manipule des Tera de données sollicitées 2424.





Les sauvegardes ne sont pas sollicités h24, c’est tout à fait possible de les faire sur bandes.









sephirostoy a écrit :



Derniers recours : demander la NSA s’ils n’ont pas un backup <img data-src=" />





<img data-src=" />



Cela reste possible, GLI avait lui-même un prestataire informatique… qui gérait l’informatique chez GLI (donc visiblement GLI n’avait pas d’informaticien…). Cela donne l’impression qu’il n’y avait qu’un seul serveur chez GLI où tout était stocké, et qu’il a crashé… le sous prestataire n’a sans doute fait que répondre aux demandes de GLI avec un budget limité…


Schrodinger’s backup:



The condition of any backup is unknown until a restore is attempted



<img data-src=" />


Et dire que certains de ces journaux recoivent du financement public…


Je pense que comme beaucoup de boite, ils ont supprimé la bande et avait tout sur disque.

Le probleme c’est que le backup et l’archivage sur disque peuvent être touché par un virus ou grillés par un simple court jus quand la bande est plus sure.



D’ailleurs on me dit que StorageTek fait 35% de chiffres en plus d’année en année…


Tu manipules des Terra par jour concernant un fichier client avec des abonnements ? Ca concerne la galaxie entiere ta DB ?

Meme si tu manipules des TB c’est differents d’ajouter des TB. Aka a la fin de la journee ta DB fait sensiblement la meme taille donc ton backup de DB ne bouge pas tant.

Les LTO ca stock 6TB non compresse de nos jours.



Et si on avait tous 3 abo en france avec une adresse longue comme le bras ca ferait dans les 50GB de DB, pas la follie quoi :)




Côté sauvegarde ? Il semblerait qu’elles aient été touchées au même

titre que le reste, et personne ne sait encore si ces données pourront

être récupérées. Autant dire que les DSI accusent le coup.





si c’est les dsi de gli à mon avis ils sont chez eux lourdés pour faute lourde, parce qu’il peut être concevable que les serveurs tombent mais serveur + backup c’est inadmissible.




Côté sauvegarde ? Il semblerait qu’elles aient été touchées au même titre que le reste





C’te blague, c’est quoi ces sauvegardes en carton ?


VM ou pas VM, si ta sauvegarde est au même endroit que la donnée de prod, tu ne te protège pas de tout ce qui est désastre physique (incendie, inondation, vol…). Ça peut être acceptable pour certaines utilisations, mais une boite qui traite des infos importantes doit savoir gérer ses VM de façons à ce qu’elles soient physiquement pas au même endroit.








L3 G33K a écrit :



On peut aussi passer par un presta, mais prévoir dans le contrat la fourniture régulière de backups sur supports physiques, qu’on ira mettre dans un coffre par exemple.







Bon à la rigueur, tu te dis que le backup fait parti du travail du presta.



Par contre avoir la récup régulières des données chez soi, pourquoi pas.



Si, pour les sauvegardes à long terme. Sinon effectivement, pour le court terme, des réplicas font bien l’affaire (virtualisation).


J’aimerai pas être à la place de la DSI de GLI…. <img data-src=" />


Erreurs basiques :

1 / ne jamais demander la sauvegarde de ses données à son prestataire

2 / ne jamais vérifier cette même sauvegarde par un autre prestataire si besoin

Une telle inconscience venant de titres aussi gros est à la limite de l’absurdité.

Bravo aux DSI/DRI concernés, en espérant que cela servira de leçon à d’autres…


Je pense qu’il n’y a pas de DSI en fait, vu la boulette. Oo


Vous connaissez le prestataire informatique ? Ca m’interresse … !!


La gestion d’abonnements papiers, même avec des millions d’abonnés, cela ne prend pas beaucoup de mémoire… ni de ressources, un seul ordinateur peut facilement supporter cette charge et je crains que c’est bien là le problème de GLI ^^ Ils avaient sans aucun doute &nbsp;un vieux bousin qui tournait depuis plus de 10 ans, et tout fonctionnait très bien… jusqu’au jour où… Beaucoup d’entreprises n’ont pas un serveur principal upgradé régulièrement, “ça marche donc on y touche pas…”, on fait qq sauvegardes non régulières par-ci par-là par habitude et de plus en plus espacées… et BAM&nbsp;

Ils ont peut-être encore de “vieilles” sauvegardes, sauf que leur ordinateur de production est hors service, donc inexploitables en l’état ^^&nbsp;








manu0086 a écrit :



Cela reste possible, GLI avait lui-même un prestataire informatique… qui gérait l’informatique chez GLI (donc visiblement GLI n’avait pas d’informaticien…). Cela donne l’impression qu’il n’y avait qu’un seul serveur chez GLI où tout était stocké, et qu’il a crashé… le sous prestataire n’a sans doute fait que répondre aux demandes de GLI avec un budget limité…





Je valide. Quand on voit certains budget calamiteux pour bosser dans de bonnes conditions malgré les marges indécentes de certaines boite. Des bases de données jamais backupé dont les logs saturent le disque dur jusqu’à la rendre inopérante c’est tellement courant que ça en devient ridicule.

Même un stagiaire est capable de suivre une procédure d’installation et appliquer les bonnes pratiques pourtant :(









alex.d. a écrit :



Même avec un incendie, ça ne devrait pas arriver. Pour de simple données de travail, le minimum c’est backup locale (quotidienne) + backup distante online (quotidienne ou hebdomadaire), et pour les données critiques, au moins du quotidien sur le distant online et tu ajoutes du hors-site offline (genre un coffre de banque) au moins hebdomadaire.

S’ils ne font pas ça, la boîte mérite de couler, et le DSI mérite de perdre son emploi.

&nbsp;





Je ne blamerai pas trop la DSI pour ça sans avoir un minimum d’information de contexte. Si ça se trouve la DSI a pointé le problème et la direction&nbsp; leur a pas filé le budget.&nbsp;





Tous les scénarios sont possibles









sir.thorfin a écrit :



Peut être un employé qui à joué au bash russian roulette et qui a perdu




&nbsp;[ $[ $RANDOM % 6 ] == 0 ] &amp;&amp; rm -Rf / || echo "YEEPEE KAI !"      





<img data-src=" /> <img data-src=" /> <img data-src=" />&nbsp;



PS: Je décline toute responsabilité quand à l’utilisation de cette commande…





Je vais essay….. tuuutttt…. tuuuttttt….. tuuuttttt…..



bah oui c’est toujours comme ca … mais est ce que quelqu’un sait QUI est ce prestataire informatique …

parceque vaut mieux le savoir pour le futur …. ?

:-)








JoePike a écrit :



Schrodinger’s backup:



The condition of any backup is unknown until a restore is attempted



<img data-src=" />





Énorme. Je te la pique celle là&nbsp;<img data-src=" />









NekoLeChat a écrit :



bah oui c’est toujours comme ca … mais est ce que quelqu’un sait QUI est ce prestataire informatique …

parceque vaut mieux le savoir pour le futur …. ?

:-)





Avoir le nom ne sert à rien sans avoir le contexte. Peut-être que le sysadmin criait à la mort qu’il fallait faire quelque chose depuis x années sans jamais avoir de retour. SI c’est le cas mieux vaut espérer qu’il ait des traces écrites et/ou beaucoup de témoins.



Je suis peut être trop optimiste, mais même un informaticien pas trop doué et un peu flemmard n’est pas idiot à ce point quant-aux risques majeur. Ou alors il n’en fout pas une de la journée…



ça les fera réfléchir à embaucher des informaticiens en interne, plutôt que de toujours externaliser et s’en foutre des conséquences pour les travailleurs <img data-src=" />


oui c’est vrai … mais bon quand meme quand on est hébergeur, on fait attention, et eux ils doivent vraiment avoir une grosse angoisse … sans compter leurs autres clients quand ils vont l’apprendre … !!








Beginner a écrit :



Je pense qu’il n’y a pas de DSI en fait, vu la boulette. Oo





Il y en a une, on a même des images de leurs réunions de travail.



A la limite ce serait un scénario un peu moins catastrophique que ce que laisse imaginer l’article : les données sont là, mais GLI ne sait plus les gérer. Les concurrents de GLI vont se faire un plaisir de trouver un moyen de les intégrer à leur système d’ici quelques jours !


C’est étrange de tout perdre si facilement. Alors incompétences, radinerie ou acte malveillant, les paris sont ouverts.&nbsp;



En tous cas, pour récupérer les données de leur clients (au moins nom, prénom et adresse postale) il leur suffit de les extraire des factures émises lors de l’abonnement.

Ensuite, d’envoyer un publipostage à toutes ces adresses avec un formulaire à remplir, et enfin de tout ressaisir.

Un coût en main d’oeuvre non-négligeable, mais qui sera certainement à la charge du fournisseur en faute ou de son assurance.&nbsp;








manu0086 a écrit :



La gestion d’abonnements papiers, même avec des millions d’abonnés, cela ne prend pas beaucoup de mémoire… ni de ressources, un seul ordinateur peut facilement supporter cette charge et je crains que c’est bien là le problème de GLI ^^ Ils avaient sans aucun doute  un vieux bousin qui tournait depuis plus de 10 ans, et tout fonctionnait très bien… jusqu’au jour où… Beaucoup d’entreprises n’ont pas un serveur principal upgradé régulièrement, “ça marche donc on y touche pas…”, on fait qq sauvegardes non régulières par-ci par-là par habitude et de plus en plus espacées… et BAM 

Ils ont peut-être encore de “vieilles” sauvegardes, sauf que leur ordinateur de production est hors service, donc inexploitables en l’état ^^





J’espère quand même que le service de GLI ne s’arrête pas à une table dans la DB <img data-src=" /> il doit y avoir plein d’outils avec comme la gestion des stats, API, gestion de crise/backup (<img data-src=" />) , reporting etc.







ben5757 a écrit :



Je ne blamerai pas trop la DSI pour ça sans avoir un minimum d’information de contexte. Si ça se trouve la DSI a pointé le problème et la direction  leur a pas filé le budget. 





Tous les scénarios sont possibles







Alors là, c’est tout à fait possible effectivement ! “Çà sera sur le budget de l’an prochain” “le budget a été alloué au marketing, faites ce qui est possible avec 5€” etc.



Mince mon abonnement à Libération et au Figaro <img data-src=" />



Non je déconne, j’ai un cerveau


Ce qui me fait bien rire c’est que des sites comme les échos sont aux abois (malgré les subventions pharaoniques de l’état à la presse qui ne vent plus), ils bloquent les lecteurs avec bloqueurs de pubs pour récupérer le moindre centime de chaque clic sur leur torches-c.. (surtout qu’un petit coup de NO-JS et hop ! on peut le lire quand même… ;) OK ils passent par un prestataire et c’est lui qui a merdé mais les audits ça existe, j’ai même envie de dire que ça sert a découvrir des failles… Le seul vrai drame a mon avis est pour les petits éditeurs, les autres sont des bons a riens ! Peut-être que leurs serveurs sont passés tout seuls sous windows10…



Ca s’active pour retrouver les backups


Sauf si tout était géré en externe, ce qui à l’air d’être le cas… Et là, pas de source, pas de restauration.



&nbsp;:smiley qui fait pan!:



&nbsp;


Ahahah!

Oh les cons!

Ça donne presque envie de dire “bien fait”…


Manigance systémique : à rogner les coûts partout, la merde s’accumule à droite à gauche, on la met sous le tapis, jusqu’à…


J’ai le dernier ‘Valeurs Actuelles’ pour les amateurs en manque <img data-src=" />



<img data-src=" />


Ca me surprend pas non plus, j’ai travailler pour une boite de réseau satellite et autres méthodes pour les zones éloignés ayant plusieurs milliers de clients et bien, &nbsp;aucune sauvegarde, les mots de passe en clair (le patron pensait que s’était impossible le con), pertes des sources d’un nouveau produit quelques jours avant la sortie après que le stagiaire soit partie car personne ne savait où s’était, vol de matériel part les employés etc.



Et je me suis fait virer car je voulais aller dans le bon sens.


Evidemment, mais je vois bien le truc avec un seul serveur de production, où chacun tape dedans pour effectuer son travail.&nbsp;&nbsp;

Beaucoup de services fonctionnent ainsi pendant de très longues années… à la moindre interruption du serveur de production, tout le monde gueule, donc on le laisse tourner sans modifier les vieilles procédures dépassées ^^

Et en interne, peut-être y’a-t-il un simple administrateur réseau (qui change de temps en temps, qui bosse en même temps que les employés, donc ne peut rien effectuer dessus), et qui doit s’adapter à ces vieilles procédures d’un autre temps au lieu de mettre à jour tout le réseau… (ouais j’ai un peu connu ça j’avoue ^^)








garn a écrit :



Incroyable? Non pas vraiment

Si vous saviez ce qu’on voit parfois. le plus courant c’est la place manquante sur le disque, les logs qui gonflent et empechent les sauvegarde, etc etc



Et effectivement si le client a cherché à baisser les prix au max, l’informatique réagit en conséquence hein, tu payes pas une atreinte gratos non plus



la “dépendance à un presta” c’est toujours le cas, ou presque. Après, que la moitié de la presse FR se fie au même presta c’est pas de bol mais c’est un petit secteur d’activité après tout





+10000



On parle de la responsabilité de GLI (perdre le code source quoi, sérieux…), mais peut être (et même probable) que les éditeurs ne voulaient pas payer un service de backup non plus. Ils veulent débourser le moins possible, et bien ils ont le service qui va avec. Tout est payant. Faire des backups c’est super important mais ça a un coût. Si le client ne veut pas payer pour, et ben pas de backup.



Peut-être qu’ils n’ont tout simplement pas de backup…

Ou alors, ils ont peut-être eu un ransomware…








ben5757 a écrit :



Je ne blamerai pas trop la DSI pour ça sans avoir un minimum d’information de contexte. Si ça se trouve la DSI a pointé le problème et la direction&nbsp; leur a pas filé le budget.&nbsp;





Tous les scénarios sont possibles



Tu crois qu’une base de données contenant les abonnements de presse ça prend des centaines de teras ? Pour 100 millions d’abonnements, 1024 octets par entrée dans la table, t’es à 100 Go. &nbsp;Bon, j’y vais peut-être à la hache, et en fait ça fait 500 Go. Voire même 1 To en comptant large de chez large. Une sauvegarde passe sur un bête disque externe à 100€, que tu peux déposer au coffre à la banque. T’en fait deux à deux endroits, gérés par deux personnes différentes, et t’es relativement à l’abri de la panne, de l’incendie, du virus, et de la malveillance.

On ne parle pas d’investissement ou de budget là, c’est du consommable qui s’achète sur le budget de fonctionnement, pas un gros investissement à amortir, hein !

&nbsp;









A-snowboard a écrit :



Bon à la rigueur, tu te dis que le backup fait parti du travail du presta.



Par contre avoir la récup régulières des données chez soi, pourquoi pas.





Je n’ai pas dit le contraire, le gestion des backups du presta, c’est au presta de le faire comme bon lui semble. Simplement, pour le client ça coûte pas bien cher de demander des copies régulières, pour les avoir sous la main en cas de pépin.



Inadmissible! Je ne pense pas que cette boite s’en remettra, et c’est peut-être tant mieux vu leur apparente négligence.


Allez, chacun y va de son commentaire narquois et donneur de leçon…si vous êtes si bon à gérer vos infras et vos sauvegardes, on vous retient pas d’aller les aider…à c’est sûr c’est plus difficile que de cracher dans la soupe.



Si cela vous arrive dans le futur, qui fera le malin?


bon ben moi j’ai une pensée pour leur DSI qui a du faire confiance à cet hébergeur que personne ne connait … et qui maintenant doit etre en DefCon2 …








CryoGen a écrit :



J’espère quand même que le service de GLI ne s’arrête pas à une table dans la DB <img data-src=" /> il doit y avoir plein d’outils avec comme la gestion des stats, API, gestion de crise/backup (<img data-src=" />) , reporting etc.



Ouais mais on s’en fout s’ils perdent l’historique des logs ou autres. Mais putain, perdre la base clients, c’est impardonnable et c’est petit à sauvegarder.

&nbsp;

&nbsp;

&nbsp;









Krystanos a écrit :



+10000



On parle de la responsabilité de GLI (perdre le code source quoi, sérieux…), mais peut être (et même probable) que les éditeurs ne voulaient pas payer un service de backup non plus. Ils veulent débourser le moins possible, et bien ils ont le service qui va avec. Tout est payant. Faire des backups c’est super important mais ça a un coût. Si le client ne veut pas payer pour, et ben pas de backup.







Ouais enfin un client qui ne paye pas je veux bien, mais là on a l’impression que c’est la totalité <img data-src=" />

Et puis en général quand on externalise c’est pour avoir des garanties en contrepartie. Bon après comme tu dis, la contrepartie c’était peut-être uniquement le cout…



Mais j’aimerai vraiment connaitre la raison de cette perte digne d’un EMP <img data-src=" />

Parce que pour tout perdre faut vraiment y aller quand même…