WEBVTT 00:00.090 --> 00:00.923 Instructeur : De 00:00.923 --> 00:02.880 nos jours, l'informatique en nuage est 00:02.880 --> 00:05.580 omniprésente, et c'est vraiment parce qu'elle présente 00:05.580 --> 00:07.290 de nombreux avantages. 00:07.290 --> 00:09.510 C'est ce sur quoi nous allons nous concentrer dans cette 00:09.510 --> 00:10.343 leçon en commençant 00:10.343 --> 00:12.930 à parler des différentes caractéristiques du nuage. 00:12.930 --> 00:15.160 Lorsque l'on parle d'informatique en nuage, il y a un certain 00:15.160 --> 00:17.670 nombre d'avantages ou de caractéristiques que l'on constate lorsque 00:17.670 --> 00:19.680 l'on choisit d'utiliser l'informatique en nuage. 00:19.680 --> 00:23.460 Il s'agit notamment de la haute disponibilité, de l'évolutivité, de l'élasticité, de 00:23.460 --> 00:24.750 l'utilisation mesurée, des ressources 00:24.750 --> 00:27.540 partagées et de la synchronisation des fichiers. 00:27.540 --> 00:29.040 Examinons-les. 00:29.040 --> 00:31.350 Tout d'abord, nous disposons d'une haute disponibilité. 00:31.350 --> 00:32.749 La haute disponibilité fait référence 00:32.749 --> 00:34.410 au fait que les services ne subissent que 00:34.410 --> 00:37.800 très peu de temps d'arrêt lorsque vous utilisez l'informatique en nuage. 00:37.800 --> 00:39.690 En effet, la plupart des services proposés 00:39.690 --> 00:41.670 dans le nuage sont conçus pour être très fiables 00:41.670 --> 00:43.200 et très tolérants aux pannes. 00:43.200 --> 00:45.900 Cela signifie que nous pouvons garantir un niveau élevé de disponibilité. 00:45.900 --> 00:47.610 En ce qui concerne la disponibilité, 00:47.610 --> 00:50.160 nous la mesurons généralement en termes de pourcentage 00:50.160 --> 00:53.760 de temps de fonctionnement par rapport au temps d'indisponibilité. 00:53.760 --> 00:55.920 Ainsi, par exemple, l'étalon-or des 00:55.920 --> 00:58.860 réseaux est connu sous le nom de "cinq neuf". 00:58.860 --> 01:02.970 Cinq neuf signifient 99. 999% de temps de fonctionnement ou de disponibilité 01:02.970 --> 01:06.390 tel que constaté par vos utilisateurs finaux. 01:06.390 --> 01:09.030 Cela signifie que nous ne pouvons avoir qu'environ 01:09.030 --> 01:11.980 5 minutes et 15 secondes de temps d'arrêt par an. 01:11.980 --> 01:15.090 C'est exact, seulement cinq minutes et 15 secondes 01:15.090 --> 01:18.570 sur l'ensemble des 365 jours d'une année. 01:18.570 --> 01:20.400 Pour ce faire, il faut des systèmes 01:20.400 --> 01:23.430 très fiables et très disponibles. 01:23.430 --> 01:25.330 Ainsi, si vous avez un site web, 01:25.330 --> 01:29.123 vous aurez au moins deux serveurs web pour l'héberger. 01:29.123 --> 01:30.300 Ainsi, si l'un des deux tombe 01:30.300 --> 01:32.160 en panne, l'autre continue à supporter la charge, 01:32.160 --> 01:35.730 ce qui signifie que l'utilisateur final ne subit aucun temps d'arrêt. 01:35.730 --> 01:36.690 C'est de cela qu'il s'agit 01:36.690 --> 01:38.640 lorsque l'on parle de haute disponibilité. 01:38.640 --> 01:42.210 Par exemple, avec mon propre site web, diontraining. com, nous disposons en fait d'une 01:42.210 --> 01:44.760 installation hautement disponible qui a été 01:44.760 --> 01:47.280 créée à l'aide de services en nuage. 01:47.280 --> 01:50.070 Ainsi, selon l'endroit d'où vous venez dans le monde, vous atteindrez 01:50.070 --> 01:51.060 l'un de nos multiples serveurs 01:51.060 --> 01:53.160 situés dans le monde entier qui est le plus proche de 01:53.160 --> 01:55.680 vous afin d'obtenir une meilleure expérience. 01:55.680 --> 01:57.627 Si votre serveur est en panne pour une raison quelconque, 01:57.627 --> 02:00.300 vous serez automatiquement redirigé vers un autre serveur un peu plus 02:00.300 --> 02:02.490 éloigné de vous, mais toujours en service. 02:02.490 --> 02:04.980 Ainsi, vous obtenez toujours le service que vous 02:04.980 --> 02:08.460 recherchez, et c'est un moyen d'assurer une haute disponibilité. 02:08.460 --> 02:10.590 La deuxième caractéristique du nuage dont nous allons 02:10.590 --> 02:12.480 parler est connue sous le nom d'évolutivité. 02:12.480 --> 02:15.150 Lorsque nous parlons d'évolutivité, il s'agit 02:15.150 --> 02:17.370 du fait que nous pouvons augmenter le nombre 02:17.370 --> 02:19.080 de personnes ou d'objets dans notre 02:19.080 --> 02:23.220 système à un rythme linéaire ou inférieur à un rythme linéaire. 02:23.220 --> 02:24.053 Ce que je veux dire 02:24.053 --> 02:26.850 par là, c'est qu'il y a 100 utilisateurs qui utilisent mon système 02:26.850 --> 02:28.620 et qu'il me coûte 10 dollars. 02:28.620 --> 02:31.282 Si je mets 200 utilisateurs sur mon système, cela devrait 02:31.282 --> 02:35.010 me coûter 20 dollars ou moins, et ce serait une échelle linéaire. 02:35.010 --> 02:37.860 Si je passais de 100 à 200 utilisateurs et que le prix passait 02:37.860 --> 02:40.500 de 10 à 100 dollars, il s'agirait d'une échelle exponentielle, 02:40.500 --> 02:43.380 ce qui n'est pas souhaitable. 02:43.380 --> 02:45.180 Ainsi, lorsque nous développons nos systèmes en nuage, 02:45.180 --> 02:47.070 nous recherchons toujours l'évolutivité, ce qui signifie 02:47.070 --> 02:49.860 que même si nous n'avons que 10 utilisateurs aujourd'hui, nous pourrions en 02:49.860 --> 02:51.090 avoir 100 demain. 02:51.090 --> 02:52.590 Le lendemain, nous en avons 1 000, le surlendemain, 02:52.590 --> 02:55.260 nous pourrions en avoir 10 000, et ainsi de suite. 02:55.260 --> 02:56.093 Si vous regardez certaines 02:56.093 --> 02:58.800 grandes entreprises comme Facebook, Google, LinkedIn et 02:58.800 --> 03:02.160 UNI, elles ont des millions d'utilisateurs finaux qui accèdent à leurs 03:02.160 --> 03:04.710 plateformes tous les jours et elles sont capables d'évoluer 03:04.710 --> 03:07.422 grâce à l'évolutivité des services en nuage, parce que je 03:07.422 --> 03:09.510 n'ai pas besoin d'acheter un autre serveur de 03:09.510 --> 03:10.710 10 000 dollars pour l'installer 03:10.710 --> 03:14.490 dans mon centre de données local, parce que je peux simplement utiliser celui d'Amazon 03:14.490 --> 03:16.650 et utiliser une partie de leur capacité en fonction 03:16.650 --> 03:19.560 de mes besoins. 03:19.560 --> 03:20.970 Pour ce qui est de l'évolutivité, 03:20.970 --> 03:22.650 il y a deux façons de procéder. 03:22.650 --> 03:25.560 La première consiste à augmenter l'échelle, ce que l'on appelle l'échelle verticale. 03:25.560 --> 03:27.090 Il s'agit d'ajouter des ressources 03:27.090 --> 03:29.010 à un serveur ou à un nœud particulier. 03:29.010 --> 03:31.020 Par exemple, si vous utilisez un serveur en nuage 03:31.020 --> 03:32.970 doté de deux unités centrales virtuelles, vous 03:32.970 --> 03:35.730 pouvez passer à quatre unités centrales virtuelles. 03:35.730 --> 03:37.170 C'est l'idée de la mise à l'échelle. 03:37.170 --> 03:38.610 Vous ajoutez des ressources, 03:38.610 --> 03:41.040 qu'il s'agisse de processeurs, de mémoire vive, 03:41.040 --> 03:43.110 de stockage, de bande passante, etc. 03:43.110 --> 03:45.120 D'autre part, il est également possible de réduire l'échelle, 03:45.120 --> 03:47.100 ce que l'on appelle la mise à l'échelle horizontale. 03:47.100 --> 03:49.440 Dans ce cas, vous utilisez toujours des machines plus petites, 03:49.440 --> 03:50.280 mais vous en utilisez un 03:50.280 --> 03:53.400 plus grand nombre qui travaillent en tandem derrière un équilibreur de charge. 03:53.400 --> 03:55.080 Ainsi, au lieu d'avoir un serveur qui gère 03:55.080 --> 03:57.316 toute la charge et de passer à l'échelle supérieure 03:57.316 --> 04:00.180 en augmentant les unités centrales et la mémoire, vous pouvez passer 04:00.180 --> 04:02.520 d'un serveur à deux serveurs, ou de deux serveurs à quatre, 04:02.520 --> 04:05.970 ou de quatre à huit, et vous pouvez continuer à progresser en ajoutant des serveurs 04:05.970 --> 04:07.170 supplémentaires derrière 04:07.170 --> 04:09.840 votre équilibreur de charge, qui vous permettront de gérer un 04:09.840 --> 04:11.940 trafic supplémentaire. 04:11.940 --> 04:13.710 Ceci nous amène à notre troisième domaine, 04:13.710 --> 04:15.864 qui est connu sous le nom d'élasticité rapide. 04:15.864 --> 04:18.960 Lorsque nous parlons d'élasticité rapide, nous parlons du fait que 04:18.960 --> 04:20.160 nous pouvons augmenter ou 04:20.160 --> 04:22.731 diminuer la taille de l'entreprise très rapidement. 04:22.731 --> 04:25.454 Pour ce faire, nous utilisons l'automatisation et 04:25.454 --> 04:28.110 l'orchestration avec de nombreuses machines virtuelles 04:28.110 --> 04:29.970 sur des serveurs physiques appartenant 04:29.970 --> 04:32.220 à Amazon, Google, Microsoft et d'autres sociétés 04:32.220 --> 04:35.040 qui nous permettent d'utiliser tout ou partie de leurs 04:35.040 --> 04:38.104 services à la demande. 04:38.104 --> 04:41.040 C'est ce qui nous donne cette élasticité rapide. 04:41.040 --> 04:43.200 Lorsque vous entendez le terme d'élasticité 04:43.200 --> 04:46.290 rapide ou d'élasticité en général, pensez qu'il s'agit de la 04:46.290 --> 04:48.785 capacité du système à gérer les changements de la 04:48.785 --> 04:50.370 demande en temps réel. 04:50.370 --> 04:51.410 Reprenons l'exemple 04:51.410 --> 04:54.780 de mon site web, diontraining. com. 04:54.780 --> 04:56.490 Si, à l'heure actuelle, je consulte 04:56.490 --> 04:58.770 mon site web et que 1 000 étudiants sont connectés, 04:58.770 --> 05:00.330 et que, dans cinq minutes, 10 000 étudiants 05:00.330 --> 05:02.520 sont connectés, mes systèmes sont conçus pour 05:02.520 --> 05:03.774 activer des ressources cloud 05:03.774 --> 05:07.230 supplémentaires et transférer une partie de la charge de ces nouveaux utilisateurs 05:07.230 --> 05:10.230 sur ces services additionnels. 05:10.230 --> 05:12.810 C'est l'idée de l'élasticité rapide. 05:12.810 --> 05:14.580 En général, lorsque vous travaillez dans le 05:14.580 --> 05:16.470 nuage, si vous avez conçu vos systèmes correctement, 05:16.470 --> 05:18.949 vous avez la possibilité d'avoir rapidement de l'élasticité 05:18.949 --> 05:21.150 et d'évoluer très rapidement, et de la même manière, lorsque 05:21.150 --> 05:23.520 la demande diminue, vous pouvez rapidement vous débarrasser 05:23.520 --> 05:24.750 de ces serveurs supplémentaires 05:24.750 --> 05:27.120 et les ramener à un niveau inférieur. 05:27.120 --> 05:28.680 La raison pour laquelle vous voulez faire 05:28.680 --> 05:31.166 cela est que tous ces serveurs supplémentaires vont vous coûter plus 05:31.166 --> 05:33.390 d'argent, et si vous n'avez pas assez d'utilisateurs pour les 05:33.390 --> 05:34.500 avoir, vous ne voulez pas payer 05:34.500 --> 05:36.510 pour cela, alors vous allez les libérer, les rendre à votre 05:36.510 --> 05:37.410 fournisseur de services 05:37.410 --> 05:40.140 pour qu'il puisse louer ce service à quelqu'un d'autre. 05:40.140 --> 05:42.750 En revanche, dans le cas d'un modèle "on premise", disons 05:42.750 --> 05:45.000 que j'ai 1 000 étudiants aujourd'hui. 05:45.000 --> 05:48.150 Eh bien, pour 1 000 étudiants, je pourrais avoir besoin de trois serveurs web. 05:48.150 --> 05:49.830 Mais si je passe à 10 000 étudiants, j'aurai 05:49.830 --> 05:51.956 besoin de 15 serveurs web supplémentaires. 05:51.956 --> 05:55.080 Pour ce faire, je devrais acheter 15 serveurs supplémentaires. 05:55.080 --> 05:55.950 Il faudrait que je les mette en rayon. 05:55.950 --> 05:57.270 Je devrais installer tous les logiciels, 05:57.270 --> 05:58.440 je devrais les configurer. 05:58.440 --> 05:59.580 Tout cela prend du temps, et 05:59.580 --> 06:02.222 les mesures d'élasticité ne sont donc pas très rapides pour que 06:02.222 --> 06:04.980 nous puissions nous développer afin de répondre à cette demande. 06:04.980 --> 06:07.860 Si vous avez un modèle d'entreprise à croissance très lente, c'est très bien. 06:07.860 --> 06:10.200 Mais si vous avez affaire à quelque chose de très rapide ou 06:10.200 --> 06:12.171 à l'une de ces plateformes modernes de médias sociaux, 06:12.171 --> 06:14.370 et que quelque chose que vous avez fait est devenu viral, 06:14.370 --> 06:16.920 et que tout le monde va sur votre site web et commence à vous inonder, 06:16.920 --> 06:19.950 si vous n'avez pas la capacité d'évoluer rapidement, vous n'aurez pas la 06:19.950 --> 06:22.052 possibilité de capturer le trafic qui provient de 06:22.052 --> 06:23.880 cet incident viral. 06:23.880 --> 06:25.620 Il faut donc être en mesure de construire 06:25.620 --> 06:27.360 son matériel de manière rapide et élastique, 06:27.360 --> 06:29.700 et c'est ce que le nuage nous permet de faire. 06:29.700 --> 06:32.910 La quatrième chose que nous avons est connue sous le nom d'utilisation mesurée. 06:32.910 --> 06:33.810 Cela nous ramène à la discussion 06:33.810 --> 06:36.510 sur l'élasticité rapide que nous venons d'avoir. 06:36.510 --> 06:38.686 Lorsque nous parlons d'utilisation mesurée, 06:38.686 --> 06:40.170 nous parlons du fait que nous payons 06:40.170 --> 06:43.800 pour un service sur la base d'un paiement à l'utilisation. 06:43.800 --> 06:46.650 Ainsi, lorsque nous utilisons un service mesuré, comme une base de données, 06:46.650 --> 06:47.730 il se peut que nous soyons facturés 06:47.730 --> 06:49.170 en fonction du nombre d'utilisateurs, 06:49.170 --> 06:52.050 du nombre de connexions ou du nombre de données stockées. 06:52.050 --> 06:53.910 En fait, nous sommes facturés sur 06:53.910 --> 06:56.910 la base de l'utilisation réelle du service consommé. 06:56.910 --> 06:59.262 Et nous le faisons soit à la seconde, soit 06:59.262 --> 07:03.480 à la minute, soit à l'heure, soit au jour le jour, soit même au mois. 07:03.480 --> 07:05.211 Par exemple, j'utilise AWS Lambda pour 07:05.211 --> 07:08.153 une grande partie de mes automatisations et fonctions backend, 07:08.153 --> 07:11.010 et ils me facturent en fonction de mon utilisation. 07:11.010 --> 07:13.290 Aujourd'hui, pour chaque million de demandes que je 07:13.290 --> 07:14.760 fais, ils me facturent 20 cents. 07:14.760 --> 07:16.200 C'est donc un moyen très efficace 07:16.200 --> 07:17.880 pour moi de réaliser mes automatisations, 07:17.880 --> 07:20.092 car c'est très, très peu coûteux. 07:20.092 --> 07:22.620 Je peux avoir des millions et des millions de demandes 07:22.620 --> 07:24.960 et cela ne me coûterait que quelques dollars, et 07:24.960 --> 07:27.090 c'est l'idée d'un service mesuré. 07:27.090 --> 07:28.334 Par ailleurs, il arrive 07:28.334 --> 07:30.120 que l'on fasse la distinction entre 07:30.120 --> 07:33.000 le service mesuré et le service mesuré. 07:33.000 --> 07:35.640 Lorsque nous parlons de services mesurés, nous parlons 07:35.640 --> 07:37.470 en fait de la même chose, c'est-à-dire 07:37.470 --> 07:38.700 de notre capacité à payer pour 07:38.700 --> 07:41.160 quelque chose sur la base de la consommation. 07:41.160 --> 07:42.840 Mais il y a une différence. 07:42.840 --> 07:44.850 Lorsque vous utilisez un service 07:44.850 --> 07:46.073 avec compteur, vous 07:46.073 --> 07:49.380 payez en fonction de votre consommation réelle. 07:49.380 --> 07:50.213 Ainsi, si vous pensez 07:50.213 --> 07:52.500 à votre facture d'eau ou d'électricité à la maison. 07:52.500 --> 07:53.880 Si vous avez ouvert votre tuyau d'arrosage 07:53.880 --> 07:55.650 et rempli votre piscine ce mois-ci, vous allez 07:55.650 --> 07:56.730 payer beaucoup plus cher votre 07:56.730 --> 07:59.670 facture d'eau parce que vous avez utilisé beaucoup plus d'eau. 07:59.670 --> 08:02.314 À l'inverse, lorsque vous traitez avec un service mesuré, 08:02.314 --> 08:04.950 c'est un peu comme votre plan de téléphone portable. 08:04.950 --> 08:08.160 Dans la plupart des pays, vous payez une redevance mensuelle pour une certaine quantité 08:08.160 --> 08:10.740 d'utilisation de votre téléphone portable, qu'il s'agisse du nombre 08:10.740 --> 08:14.100 de SMS, de minutes ou de données que vous êtes autorisé à consommer. 08:14.100 --> 08:15.390 Et lorsque vous atteignez cette limite, 08:15.390 --> 08:17.790 ils interrompent votre service et ne vous en donnent plus jusqu'à 08:17.790 --> 08:19.440 ce que vous les payiez à nouveau. 08:19.440 --> 08:21.300 Ainsi, lorsque vous pensez à un service mesuré, 08:21.300 --> 08:23.310 pensez au fait que vous payez d'avance une certaine 08:23.310 --> 08:25.920 quantité et que, que vous l'utilisiez ou non, vous avez déjà 08:25.920 --> 08:27.660 payé pour cette quantité. 08:27.660 --> 08:28.493 Mais dans le cas d'un service 08:28.493 --> 08:30.420 avec compteur, vous payez pour la quantité exacte que 08:30.420 --> 08:31.253 vous utilisez. 08:31.253 --> 08:33.480 Et c'est vraiment l'un des avantages de l'utilisation de l'informatique 08:33.480 --> 08:35.527 en nuage, car la plupart des choses se font sur la base d'un compteur, 08:35.527 --> 08:37.883 c'est-à-dire que vous ne payez que pour ce que vous utilisez. 08:37.883 --> 08:41.160 Nous allons maintenant parler des ressources partagées. 08:41.160 --> 08:43.740 Lorsque nous parlons de ressources partagées, nous 08:43.740 --> 08:46.530 parlons en fait de la possibilité de minimiser nos coûts en 08:46.530 --> 08:48.330 plaçant nos machines virtuelles sur 08:48.330 --> 08:50.220 les serveurs de quelqu'un d'autre. 08:50.220 --> 08:51.930 Les serveurs que nous utilisons 08:51.930 --> 08:54.238 pour Amazon, Azure et Google Cloud 08:54.238 --> 08:56.022 coûtent 10, 20 ou 30 000 dollars 08:56.022 --> 08:58.980 pour un serveur de bonne qualité. 08:58.980 --> 09:00.151 Ainsi, si vous devez en acheter 09:00.151 --> 09:02.640 un pour héberger votre blog WordPress, vous n'utilisez pas 09:02.640 --> 09:04.680 vraiment toute cette capacité, car si vous n'avez 09:04.680 --> 09:06.420 que quelques centaines de lecteurs, la charge 09:06.420 --> 09:08.100 ne sera pas si importante. 09:08.100 --> 09:10.020 Il est donc beaucoup plus judicieux de 09:10.020 --> 09:12.660 prendre ce serveur très coûteux, de le découper en 09:12.660 --> 09:14.550 petits morceaux et de le distribuer 09:14.550 --> 09:16.158 sous forme de machines virtuelles 09:16.158 --> 09:18.450 à tous ceux qui veulent l'utiliser. 09:18.450 --> 09:20.816 Nous pourrions donc héberger 50 ou 100 blogs 09:20.816 --> 09:24.480 WordPress sur ce serveur au lieu d'en héberger un seul. 09:24.480 --> 09:26.760 C'est l'idée d'utiliser des ressources partagées. 09:26.760 --> 09:28.330 Lorsque nous parlons de ressources partagées, 09:28.330 --> 09:30.697 nous parlons de rassembler tout le matériel qui compose le centre 09:30.697 --> 09:33.150 de données du fournisseur de services en nuage. 09:33.150 --> 09:35.215 De cette manière, il n'est pas dédié à un seul individu 09:35.215 --> 09:37.987 mais nous pouvons tous l'utiliser sur la base d'une élasticité 09:37.987 --> 09:41.220 rapide car, espérons-le, ce qu'Amazon, Google et Azure pensent, c'est 09:41.220 --> 09:42.690 que lorsqu'il y a des périodes de forte 09:42.690 --> 09:44.970 demande pour mon entreprise, il peut y avoir des périodes 09:44.970 --> 09:48.090 de faible demande pour la vôtre et vice-versa. 09:48.090 --> 09:50.280 Ainsi, au lieu d'avoir des ressources matérielles 09:50.280 --> 09:51.480 dédiées à chacune de nos entreprises, 09:51.480 --> 09:54.009 nous pouvons partager ces ressources. 09:54.009 --> 09:55.500 Enfin, la dernière caractéristique 09:55.500 --> 09:58.710 du nuage est la possibilité de synchroniser les fichiers. 09:58.710 --> 10:01.103 L'avantage de l'utilisation d'une ressource basée sur l'informatique 10:01.103 --> 10:02.760 en nuage est qu'il est possible de mettre quelque 10:02.760 --> 10:04.649 chose à un endroit et de l'étendre à d'autres endroits 10:04.649 --> 10:07.500 en fonction de la façon dont vous l'avez configuré. 10:07.500 --> 10:09.420 Par exemple, dans mon entreprise, nous dépendons 10:09.420 --> 10:11.428 beaucoup de la synchronisation des fichiers parce 10:11.428 --> 10:14.249 que la plupart de nos employés sont des employés à distance qui travaillent 10:14.249 --> 10:17.640 dans le monde entier, et pas seulement dans nos propres bureaux. 10:17.640 --> 10:18.473 Alors que je suis assis 10:18.473 --> 10:20.100 dans mon bureau en train d'enregistrer, 10:20.100 --> 10:22.830 j'ai besoin d'un moyen pour donner ce fichier à ma graphiste afin qu'elle 10:22.830 --> 10:24.690 puisse créer toutes les différentes choses que 10:24.690 --> 10:27.060 vous voyez à l'écran pendant que je parle. 10:27.060 --> 10:28.260 Elle va ensuite l'envoyer 10:28.260 --> 10:31.320 dans un autre pays où se trouve mon monteur vidéo. 10:31.320 --> 10:33.060 Lorsqu'ils auront terminé, ils renverront le 10:33.060 --> 10:34.410 document à mes bureaux où l'un de mes 10:34.410 --> 10:36.870 collaborateurs effectuera nos contrôles d'assurance qualité, 10:36.870 --> 10:38.400 puis nous l'enverrons à un autre pays qui 10:38.400 --> 10:39.300 le téléchargera ensuite 10:39.300 --> 10:41.040 sur le site final où vous le verrez. 10:41.040 --> 10:43.779 Ainsi, cette vidéo a probablement voyagé dans quatre 10:43.779 --> 10:46.680 ou cinq endroits différents avant d'aboutir au produit 10:46.680 --> 10:49.470 fini que vous voyez en ce moment à l'écran. 10:49.470 --> 10:50.303 C'est l'idée de la synchronisation 10:50.303 --> 10:52.950 des fichiers, car lorsque j'enregistre ceci, je l'enregistre sur 10:52.950 --> 10:55.129 un serveur de fichiers basé sur le cloud, tous les membres 10:55.129 --> 10:57.780 de mon équipe peuvent accéder à ce fichier parce que nous avons cette 10:57.780 --> 11:00.360 copie synchronisée sur tous leurs appareils et sur tous nos serveurs 11:00.360 --> 11:03.030 dans le monde entier, de sorte qu'ils peuvent y accéder et faire ce 11:03.030 --> 11:05.430 qu'ils ont à faire. 11:05.430 --> 11:06.630 Ainsi, tout ce 11:06.630 --> 11:08.190 qui doit se passer 11:08.190 --> 11:11.070 entre l'enregistrement et la publication, 11:11.070 --> 11:16.920 puis le visionnage, peut se faire sur tous ces serveurs de manière 11:16.920 --> 11:20.730 très rationnelle. 11:20.730 --> 11:22.200 Et c'est l'un des grands avantages de 11:22.200 --> 11:24.420 l'informatique dématérialisée du point de vue de l'entreprise 11:24.420 --> 11:26.970 : vous n'avez pas de serveur dans votre bureau. 11:26.970 --> 11:28.201 Il se trouve maintenant 11:28.201 --> 11:31.650 dans le nuage, dans un centre de données protégé, hautement disponible, 11:31.650 --> 11:32.980 capable d'évoluer et de répondre 11:32.980 --> 11:34.617 de manière élastique aux demandes 11:34.617 --> 11:37.740 de périodes plus ou moins longues. 11:37.740 --> 11:39.015 Nous ne payons que ce que nous utilisons 11:39.015 --> 11:41.177 et nous pouvons partager des ressources avec d'autres personnes 11:41.177 --> 11:42.537 que nous ne connaissons peut-être même 11:42.537 --> 11:45.480 pas parce que nous sommes tous assis sur le même serveur physique. 11:45.480 --> 11:46.820 Ce sont toutes ces choses dont nous parlons 11:46.820 --> 11:49.110 lorsque nous commençons à évoquer les caractéristiques de l'informatique 11:49.110 --> 11:50.970 dématérialisée et les raisons pour lesquelles de nombreuses 11:50.970 --> 11:53.740 entreprises dans le monde entier ont migré vers l'informatique dématérialisée.