Bonsoir à tous, après avoir fait le tour des principaux guides et forums en
ligne dédiés à l'hébergement, je me suis finalement décidé pour l'offre
golem silver + infogérance proposée par Digital Network sur le site
www.dns-fr.com
J'aurai aimé savoir si certains d'entre vous ont déjà testés cette offre
et/ou cet hébergeur ?
Donc c'est de la mutualisation .. "je me sers d'une branche de ma boite ultra beneficiaire pour éponger une branche qui vend a perte"
Non, ça s'appelle un exemple :) De plus je te le répète : l'infogérance (il ne s'agit pas d'infogérance, mais d'une option d'infogérance sur *nos* serveurs à ce prix là), est, même de bout en bout, totalement bénéficiaire, et pas qu'un peu.
Encore donc, politique de tarif décorellée des couts ... ca ne fonctionne qu'un temps.
Dans mon cadre ce ne sont que des plus, tout est rentable de bout en bout. Idem pour le transit, je n'ai jamais vendu du ma vie, ne serait- ce que 1 Mb/s à perte, même aux prix qui te semblent anormaux. Aucun dumping : tout Mb/s acheté est provisionné.
Mais ca ne rentre pas dans ce qu'un client lambda apellerai "infogérance totale" .. lui, il a un besoin, il l'exprime .. je vois bien la tete de mes clients si je leur disait demain "ah non, désolé, horde c'est vraiment la merde a maintenir, on l'a viré de votre machine" :)
Parce que toi tu raisonnes dans le cas d'une infogérance externe, là c'est nous qui avons la maitrise de bout en bout du produit. Le client t'exprime des besoins, et tu y réponds par les solutions les mieux adaptées, peu importe lesquelles pour lui. A contrario, il faut savoir dire (ce que l'on fait) "non" quand il le faut.
Rhalala .. quand j'serais chomeur, faudra que j'aille me faire embaucher dans ces boites ou tout est automatique et ou les admins n'ont plus qu'a fumer leurs clopes en regardant le café couler :)
oui, enfin, genre un downgrade apache ou php c'est un "make install" hein ;)
Donc c'est de la mutualisation .. "je me sers d'une branche de ma boite
ultra beneficiaire pour éponger une branche qui vend a perte"
Non, ça s'appelle un exemple :) De plus je te le répète :
l'infogérance (il ne s'agit pas d'infogérance, mais d'une option
d'infogérance sur *nos* serveurs à ce prix là), est, même de bout en
bout, totalement bénéficiaire, et pas qu'un peu.
Encore donc, politique de tarif décorellée des couts ... ca ne
fonctionne qu'un temps.
Dans mon cadre ce ne sont que des plus, tout est rentable de bout en
bout. Idem pour le transit, je n'ai jamais vendu du ma vie, ne serait-
ce que 1 Mb/s à perte, même aux prix qui te semblent anormaux. Aucun
dumping : tout Mb/s acheté est provisionné.
Mais ca ne rentre pas dans ce qu'un client lambda apellerai "infogérance
totale" .. lui, il a un besoin, il l'exprime .. je vois bien la tete de
mes clients si je leur disait demain "ah non, désolé, horde c'est
vraiment la merde a maintenir, on l'a viré de votre machine" :)
Parce que toi tu raisonnes dans le cas d'une infogérance externe, là
c'est nous qui avons la maitrise de bout en bout du produit. Le client
t'exprime des besoins, et tu y réponds par les solutions les mieux
adaptées, peu importe lesquelles pour lui. A contrario, il faut savoir
dire (ce que l'on fait) "non" quand il le faut.
Rhalala .. quand j'serais chomeur, faudra que j'aille me faire embaucher
dans ces boites ou tout est automatique et ou les admins n'ont plus qu'a
fumer leurs clopes en regardant le café couler :)
oui, enfin, genre un downgrade apache ou php c'est un "make install"
hein ;)
Donc c'est de la mutualisation .. "je me sers d'une branche de ma boite ultra beneficiaire pour éponger une branche qui vend a perte"
Non, ça s'appelle un exemple :) De plus je te le répète : l'infogérance (il ne s'agit pas d'infogérance, mais d'une option d'infogérance sur *nos* serveurs à ce prix là), est, même de bout en bout, totalement bénéficiaire, et pas qu'un peu.
Encore donc, politique de tarif décorellée des couts ... ca ne fonctionne qu'un temps.
Dans mon cadre ce ne sont que des plus, tout est rentable de bout en bout. Idem pour le transit, je n'ai jamais vendu du ma vie, ne serait- ce que 1 Mb/s à perte, même aux prix qui te semblent anormaux. Aucun dumping : tout Mb/s acheté est provisionné.
Mais ca ne rentre pas dans ce qu'un client lambda apellerai "infogérance totale" .. lui, il a un besoin, il l'exprime .. je vois bien la tete de mes clients si je leur disait demain "ah non, désolé, horde c'est vraiment la merde a maintenir, on l'a viré de votre machine" :)
Parce que toi tu raisonnes dans le cas d'une infogérance externe, là c'est nous qui avons la maitrise de bout en bout du produit. Le client t'exprime des besoins, et tu y réponds par les solutions les mieux adaptées, peu importe lesquelles pour lui. A contrario, il faut savoir dire (ce que l'on fait) "non" quand il le faut.
Rhalala .. quand j'serais chomeur, faudra que j'aille me faire embaucher dans ces boites ou tout est automatique et ou les admins n'ont plus qu'a fumer leurs clopes en regardant le café couler :)
oui, enfin, genre un downgrade apache ou php c'est un "make install" hein ;)
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
1) C'est faux :) Il est parfaitement possible d'avoir une garantie de provisionnement de 400 Mb/s par exemple tout en achetant 250 Mb/s, attention je ne parle pas de commit et de burst mais bien de transit garanti contractuellement.
Ha? Cogent garantis contractuellement le provisionning ? ;-) Ils te garantissent également qu'ils provisionnent ce que tu as acheté vers ATDN, 3215, sprint and co? Douce utopie ;)
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
1) C'est faux :) Il est parfaitement possible d'avoir une garantie de
provisionnement de 400 Mb/s par exemple tout en achetant 250 Mb/s,
attention je ne parle pas de commit et de burst mais bien de transit
garanti contractuellement.
Ha? Cogent garantis contractuellement le provisionning ? ;-)
Ils te garantissent également qu'ils provisionnent ce que tu as
acheté vers ATDN, 3215, sprint and co? Douce utopie ;)
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
1) C'est faux :) Il est parfaitement possible d'avoir une garantie de provisionnement de 400 Mb/s par exemple tout en achetant 250 Mb/s, attention je ne parle pas de commit et de burst mais bien de transit garanti contractuellement.
Ha? Cogent garantis contractuellement le provisionning ? ;-) Ils te garantissent également qu'ils provisionnent ce que tu as acheté vers ATDN, 3215, sprint and co? Douce utopie ;)
Arnaud
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
même temps, on ne va pas dévoiler toutes les méthodes (il y en a beaucoup), on est pas là non plus pour donner des solutions aux concurrents/confrères :)
En même temps, une société qui ne publie pas ses comptes à sans doutes beaucoup de choses à cacher ;)
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
même temps, on ne va pas dévoiler toutes les méthodes (il y en a
beaucoup), on est pas là non plus pour donner des solutions aux
concurrents/confrères :)
En même temps, une société qui ne publie pas ses comptes à sans doutes
beaucoup de choses à cacher ;)
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
même temps, on ne va pas dévoiler toutes les méthodes (il y en a beaucoup), on est pas là non plus pour donner des solutions aux concurrents/confrères :)
En même temps, une société qui ne publie pas ses comptes à sans doutes beaucoup de choses à cacher ;)
Dominique ROUSSEAU
Le lun, 20 aoû 2007 at 09:40 GMT, Arnaud a écrit :
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
même temps, on ne va pas dévoiler toutes les méthodes (il y en a beaucoup), on est pas là non plus pour donner des solutions aux concurrents/confrères :)
En même temps, une société qui ne publie pas ses comptes à sans doutes beaucoup de choses à cacher ;)
Et c'est sans compter les spams qu'ils envoient :o)
Le lun, 20 aoû 2007 at 09:40 GMT, Arnaud <abermingham@pasdespam-corp.free.fr> a écrit :
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
même temps, on ne va pas dévoiler toutes les méthodes (il y en a
beaucoup), on est pas là non plus pour donner des solutions aux
concurrents/confrères :)
En même temps, une société qui ne publie pas ses comptes à sans doutes
beaucoup de choses à cacher ;)
Et c'est sans compter les spams qu'ils envoient :o)
Le lun, 20 aoû 2007 at 09:40 GMT, Arnaud a écrit :
Le Sun, 19 Aug 2007 16:34:19 -0700, christophe.casalegno a écrit :
même temps, on ne va pas dévoiler toutes les méthodes (il y en a beaucoup), on est pas là non plus pour donner des solutions aux concurrents/confrères :)
En même temps, une société qui ne publie pas ses comptes à sans doutes beaucoup de choses à cacher ;)
Et c'est sans compter les spams qu'ils envoient :o)
filh
Spyou wrote:
Spyou wrote:
Si on compte 2 versions de PHP par mois et 20 sites par machine, on est deja aux 2h de boulot précités ... sans compter tout le reste.
Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!) de php par mois.
Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes les mises a jour du PHP Group, mais seulement une de temps en temps ?
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Mais bon:)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Spyou <root@spyou.org> wrote:
Spyou wrote:
Si on compte 2 versions de PHP par mois et 20 sites par machine, on est
deja aux 2h de boulot précités ... sans compter tout le reste.
Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!)
de php par mois.
Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes
les mises a jour du PHP Group, mais seulement une de temps en temps ?
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les
mises a jour en quasi temps reel, accompagné d'un petit changelog et
d'une liste de trous de sécurités corrigés depuis l'ancienne version
pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui
marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour
forcenée aue le contraire.
Mais bon:)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Si on compte 2 versions de PHP par mois et 20 sites par machine, on est deja aux 2h de boulot précités ... sans compter tout le reste.
Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!) de php par mois.
Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes les mises a jour du PHP Group, mais seulement une de temps en temps ?
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Mais bon:)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Spyou
Spyou wrote:
Spyou wrote:
Si on compte 2 versions de PHP par mois et 20 sites par machine, on est deja aux 2h de boulot précités ... sans compter tout le reste.
Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!) de php par mois.
Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes les mises a jour du PHP Group, mais seulement une de temps en temps ?
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a jour forcenée avec un bon check de fonctionnement par la suite ... quand la distrib ne propose pas la mise a jour, c'est vite l'enfer :)
Spyou <root@spyou.org> wrote:
Spyou wrote:
Si on compte 2 versions de PHP par mois et 20 sites par machine, on est
deja aux 2h de boulot précités ... sans compter tout le reste.
Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!)
de php par mois.
Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes
les mises a jour du PHP Group, mais seulement une de temps en temps ?
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les
mises a jour en quasi temps reel, accompagné d'un petit changelog et
d'une liste de trous de sécurités corrigés depuis l'ancienne version
pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui
marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour
forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a
jour forcenée avec un bon check de fonctionnement par la suite ... quand
la distrib ne propose pas la mise a jour, c'est vite l'enfer :)
Si on compte 2 versions de PHP par mois et 20 sites par machine, on est deja aux 2h de boulot précités ... sans compter tout le reste.
Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!) de php par mois.
Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes les mises a jour du PHP Group, mais seulement une de temps en temps ?
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a jour forcenée avec un bon check de fonctionnement par la suite ... quand la distrib ne propose pas la mise a jour, c'est vite l'enfer :)
filh
Spyou wrote:
Spyou wrote:
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a jour forcenée avec un bon check de fonctionnement par la suite ...
Hum... rêvons un peu : - imaginons que nous avons un truc genre horde au complet, puis par ailleurs un truc genre typo3 avec quelques modules ajoutés (pas beaucoup hein, mettons une trentaine). - et puis aussi quelques (mettons 20 ou 30) appli webs développées en local, avec mettons quand même un peu de SSO...
Le « bon check » ça prend grosso modo 3 semaines :)
quand la distrib ne propose pas la mise a jour, c'est vite l'enfer :)
Meuh non :) Il faut aussi savoir stabiliser des choses, c'est peut-être la maladie de linux ça :avoir du mal à stabiliser :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Spyou <root@spyou.org> wrote:
Spyou <root@spyou.org> wrote:
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les
mises a jour en quasi temps reel, accompagné d'un petit changelog et
d'une liste de trous de sécurités corrigés depuis l'ancienne version
pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui
marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour
forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a
jour forcenée avec un bon check de fonctionnement par la suite ...
Hum... rêvons un peu :
- imaginons que nous avons un truc genre horde au complet, puis par
ailleurs un truc genre typo3 avec quelques modules ajoutés (pas beaucoup
hein, mettons une trentaine).
- et puis aussi quelques (mettons 20 ou 30) appli webs développées en
local, avec mettons quand même un peu de SSO...
Le « bon check » ça prend grosso modo 3 semaines :)
quand
la distrib ne propose pas la mise a jour, c'est vite l'enfer :)
Meuh non :) Il faut aussi savoir stabiliser des choses, c'est peut-être
la maladie de linux ça :avoir du mal à stabiliser :)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a jour forcenée avec un bon check de fonctionnement par la suite ...
Hum... rêvons un peu : - imaginons que nous avons un truc genre horde au complet, puis par ailleurs un truc genre typo3 avec quelques modules ajoutés (pas beaucoup hein, mettons une trentaine). - et puis aussi quelques (mettons 20 ou 30) appli webs développées en local, avec mettons quand même un peu de SSO...
Le « bon check » ça prend grosso modo 3 semaines :)
quand la distrib ne propose pas la mise a jour, c'est vite l'enfer :)
Meuh non :) Il faut aussi savoir stabiliser des choses, c'est peut-être la maladie de linux ça :avoir du mal à stabiliser :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a jour forcenée avec un bon check de fonctionnement par la suite ...
Hum... rêvons un peu : - imaginons que nous avons un truc genre horde au complet, puis par ailleurs un truc genre typo3 avec quelques modules ajoutés (pas beaucoup hein, mettons une trentaine). - et puis aussi quelques (mettons 20 ou 30) appli webs développées en local, avec mettons quand même un peu de SSO...
Le « bon check » ça prend grosso modo 3 semaines :)
Aahhh mais non, c'est la qu'intervient le discours magique "monsieur, si vous voulez qu'on check vos sites, faites une page qui affiche des "OK" quand les fonctions que vous utilisez dans votre code se comporte convenablement".
3 semaines -> 1h :)
Spyou <root@spyou.org> wrote:
Spyou <root@spyou.org> wrote:
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les
mises a jour en quasi temps reel, accompagné d'un petit changelog et
d'une liste de trous de sécurités corrigés depuis l'ancienne version
pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui
marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour
forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a
jour forcenée avec un bon check de fonctionnement par la suite ...
Hum... rêvons un peu :
- imaginons que nous avons un truc genre horde au complet, puis par
ailleurs un truc genre typo3 avec quelques modules ajoutés (pas beaucoup
hein, mettons une trentaine).
- et puis aussi quelques (mettons 20 ou 30) appli webs développées en
local, avec mettons quand même un peu de SSO...
Le « bon check » ça prend grosso modo 3 semaines :)
Aahhh mais non, c'est la qu'intervient le discours magique "monsieur, si
vous voulez qu'on check vos sites, faites une page qui affiche des "OK"
quand les fonctions que vous utilisez dans votre code se comporte
convenablement".
J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les mises a jour en quasi temps reel, accompagné d'un petit changelog et d'une liste de trous de sécurités corrigés depuis l'ancienne version pour savoir si oui ou non il faut mettre a jour.
Ouaip, mais bon c'est le meilleur moyen pour planter des choses qui marchaient aussi.
J'aurais tendance à dire : if it works, don't fix it :)
Je vois plus souvent des dégats dûs à une politique de mise à jour forcenée aue le contraire.
Ca, c'est une question de politique. On peut aussi faire de la mise a jour forcenée avec un bon check de fonctionnement par la suite ...
Hum... rêvons un peu : - imaginons que nous avons un truc genre horde au complet, puis par ailleurs un truc genre typo3 avec quelques modules ajoutés (pas beaucoup hein, mettons une trentaine). - et puis aussi quelques (mettons 20 ou 30) appli webs développées en local, avec mettons quand même un peu de SSO...
Le « bon check » ça prend grosso modo 3 semaines :)
Aahhh mais non, c'est la qu'intervient le discours magique "monsieur, si vous voulez qu'on check vos sites, faites une page qui affiche des "OK" quand les fonctions que vous utilisez dans votre code se comporte convenablement".
3 semaines -> 1h :)
Spyou
En même temps, une société qui ne publie pas ses comptes à sans doutes beaucoup de choses à cacher ;)
En même temps, dédibox ne publit pas, il me semble ...
En meme temps, Arnaud n'est pas gérant de dédibox, et puis surtout, dedibox est une filiale d'iliad, et comme toute bonne filiale qui se respecte, ses comptes sont inclus dans ceux de la maison mere qui, elle, les publie, bourse oblige.
Surtout qu'une fois qu'ovanet s'est mis à publié, on a vite découvert que tout tes beaux discours (1M€ de CA & co) était du flan...
Ceci dit, un bruit de couloir dernierement venu a mes oreilles disait que dedibox allait publier des comptes séparés, juste pour le principe ... flan ou pas, l'avenir nous le dira.
En même temps, une société qui ne publie pas ses comptes à sans doutes
beaucoup de choses à cacher ;)
En même temps, dédibox ne publit pas, il me semble ...
En meme temps, Arnaud n'est pas gérant de dédibox, et puis surtout,
dedibox est une filiale d'iliad, et comme toute bonne filiale qui se
respecte, ses comptes sont inclus dans ceux de la maison mere qui, elle,
les publie, bourse oblige.
Surtout qu'une fois qu'ovanet s'est mis à publié, on a vite découvert
que tout tes beaux discours (1M€ de CA & co) était du flan...
Ceci dit, un bruit de couloir dernierement venu a mes oreilles disait
que dedibox allait publier des comptes séparés, juste pour le principe
... flan ou pas, l'avenir nous le dira.
En même temps, une société qui ne publie pas ses comptes à sans doutes beaucoup de choses à cacher ;)
En même temps, dédibox ne publit pas, il me semble ...
En meme temps, Arnaud n'est pas gérant de dédibox, et puis surtout, dedibox est une filiale d'iliad, et comme toute bonne filiale qui se respecte, ses comptes sont inclus dans ceux de la maison mere qui, elle, les publie, bourse oblige.
Surtout qu'une fois qu'ovanet s'est mis à publié, on a vite découvert que tout tes beaux discours (1M€ de CA & co) était du flan...
Ceci dit, un bruit de couloir dernierement venu a mes oreilles disait que dedibox allait publier des comptes séparés, juste pour le principe ... flan ou pas, l'avenir nous le dira.
