«Cloud sovrano». Due parole che si pronunciano con solennità nelle riunioni, ma che non significano nulla finché non vengono sviscerate. La maggior parte dei dirigenti che le usano crede di acquistare il colore di una bandiera. In realtà acquistano un contratto, soggetto a una normativa, gestito da qualcuno. Il resto è solo facciata.
Analizziamo i termini. Senza accusare nessuno e senza teatralità.
Il significato principale del termine
Il termine «cloud» non deriva da una metafora poetica, bensì da un disegno. A partire dagli anni ’70-’80, gli ingegneri di rete rappresentavano con una piccola nuvola quella parte dell’infrastruttura che non controllavano: dapprima la rete estesa dell’operatore di telecomunicazioni, la WAN, poi Internet nella sua interezza. Una convenzione grafica, nient’altro. Ciò che si controlla, lo si disegna con riquadri e cavi. Ciò che non si controlla, lo si disegna come una nuvola. Il termine è passato dallo schema al mercato, ma l’idea originale rimane valida: il cloud è quella parte dell’informatica che sfugge al vostro controllo diretto.
Da qui una serie di preconcetti da sfatare. iCloud non è cloud computing: è un servizio di sincronizzazione dei file tra i dispositivi Apple. Nemmeno Google Drive lo è: si tratta di archiviazione online. «Tutto ciò che non si trova nei nostri data center» non è una definizione. «Ospitato in Francia» nemmeno. Queste semplificazioni confondono un utilizzo da parte del grande pubblico o una localizzazione con un modello di fornitura specifico.
Tale modello è stato definito dal NIST nel 2011, nella pubblicazione SP 800-145, e da allora funge da riferimento mondiale. Cinque criteri cumulativi definiscono il cloud computing: il self-service su richiesta (il cliente provvede autonomamente all’allocazione delle proprie risorse, senza alcun intervento umano da parte del fornitore), l’accesso alla rete a banda larga (le risorse sono disponibili sulla rete tramite meccanismi standard), la condivisione delle risorse (lo stesso parco hardware serve più clienti, i quali ignorano l’esatta ubicazione dei propri dati), l’elasticità rapida (la capacità aumenta e diminuisce quasi in tempo reale) e il servizio misurato (l’utilizzo viene conteggiato e fatturato in base al consumo). Un servizio che non soddisfa questi cinque requisiti non è cloud nel senso stretto del termine: si tratta di hosting dedicato o di gestione in outsourcing.
Deloitte riassume il cambiamento con una formula: il cloud è la trasformazione dell’informatica in un servizio pubblico, sul modello dell’elettricità. Non si produce la propria energia elettrica, la si preleva dalla rete e si paga in base a quanto rileva il contatore. Il cloud applica questa logica all’elaborazione e all’archiviazione. È utile tenere presente questa prospettiva: ciò che si acquista non è una macchina, ma un allacciamento.
Un cloud non è un luogo, è un contratto
Si tende a immaginare il cloud come un luogo, una nuvola, da qualche parte lassù. È l’opposto di un luogo. Capacità informatica noleggiata su richiesta, fatturata in base all’utilizzo, gestita da una terza parte. Tre livelli, dal più grezzo al più rifinito. L’infrastruttura (IaaS): noleggiate macchine e spazio di archiviazione. La piattaforma (PaaS): noleggiate ciò che serve per far funzionare le vostre applicazioni senza dover gestire i server. Il software (SaaS): noleggiate l’applicazione completa, la vostra posta elettronica, il vostro CRM.
A ogni livello, delegate sempre di più. A ogni livello, qualcun altro detiene le chiavi dei vostri dati. La domanda utile non è «dove sono i miei dati». È «chi può accedervi e con quale autorizzazione».
Cosa si intende per «cloud» quando si parla di OVH e AWS
La tabella di Deloitte fornisce un semplice punto di riferimento. Acquistare servizi cloud non significa acquistare un dispositivo, ma un collegamento. Non si possiede la centrale elettrica, si collega una spina e si preleva l’energia di cui si ha bisogno. La fattura segue il contatore: si paga ciò che il proprio consumo indica, né più né meno. La domanda fondamentale sorge subito dopo. Tutto ciò che il mercato raggruppa sotto il termine «cloud» soddisfa davvero i cinque criteri della definizione NIST, oppure si tratta talvolta di qualcos’altro che è stato ribattezzato per seguire la moda?
AWS risponde alla domanda nel modo più chiaro possibile. Lanciato nel 2006, il servizio ha costruito un’infrastruttura globale che soddisfa i cinque criteri punto per punto. Self-service totale: una console, API, Terraform; si effettua il provisioning senza dover parlare con nessuno. Accesso di rete universale: la risorsa è fruibile da qualsiasi terminale connesso. Condivisione su scala planetaria: decine di regioni, milioni di clienti su una piattaforma condivisa. Elasticità al millisecondo: è possibile aumentare o ridurre il carico senza preavviso. Fatturazione al tick: il contatore registra ogni secondo, ogni richiesta, ogni gigabyte trasferito. Su questa piattaforma, centinaia di servizi gestiti, tutti interoperabili, trasformano l’informatica in un servizio trasparente come la corrente elettrica. Si tratta dell’industrializzazione del modello Deloitte portata su larga scala.
OVH, diventata OVHcloud nel 2021, racconta una storia diversa. L’azienda nasce nel 1999 come provider di hosting di server dedicati e cresce vendendo potenza lorda al miglior prezzo di mercato. Il modello funziona su server dedicati, shared hosting e VPS: si affitta una macchina o una parte di essa, la si mantiene e si paga un canone mensile. Quando il mercato si è orientato verso il modello della connessione elastica, l’azienda ha semplicemente aggiunto la parola «cloud» al proprio catalogo esistente.
Tuttavia, una parte di tale catalogo non soddisfa i cinque criteri. Un server dedicato non presenta elasticità: si tratta di una macchina fissa che si noleggia mensilmente, non di una risorsa che si espande e si contrae su richiesta. Alcuni VPS non vengono fatturati in base all’utilizzo in tempo reale, ma con un canone forfettario. Alcuni servizi non offrono il self-service completo che definisce il modello. Non si tratta di un giudizio di valore, ma della definizione del NIST applicata alla lettera. Gran parte di queste offerte rientra nell’ambito dell’hosting, non del cloud in senso stretto.
Il cambio di nome in OVHcloud ne è il riflesso commerciale: si appiccica la parola «cloud» a un’offerta eterogenea per rimanere al passo con le tendenze del momento. OVH rimane un attore importante nel mercato dell’hosting low-cost su larga scala, e questo mercato ha una sua legittimità. Ma l’amalgama tra questo hosting e il cloud industrializzato distorce la lettura, poiché mette sullo stesso piano due prodotti che non funzionano secondo la stessa logica.
Questa differenza non è affatto casuale: riflette due contesti industriali che non disponevano delle stesse risorse. AWS si sta sviluppando in un Paese di trecentotrenta milioni di abitanti, in un mercato interno omogeneo in cui un’offerta, una volta implementata, si rivolge immediatamente a una base clienti immensa. Il capitale di rischio vi affluisce senza limiti, pronto a finanziare anni di perdite per costruire un’infrastruttura globale. E lo Stato federale funge da primo cliente di riferimento, dai contratti del Pentagono a quelli della CIA, il che garantisce un mercato di sbocco enorme e una garanzia di credibilità. OVH cresce in un contesto in cui nessuna di queste tre condizioni è presente: un mercato frammentato in base alle lingue e alle legislazioni nazionali, un capitale di rischio scarso e cauto, appalti pubblici che non si rivolgono spontaneamente a un attore locale emergente. Non è una questione di talento né di ambizione, ma di mezzi strutturali. Non si costruisce la stessa cosa con le stesse mani quando il terreno sotto i piedi non è lo stesso.
Questa disparità di partenza è essa stessa una dimensione della sovranità digitale, e la più spesso trascurata. Quando si parla di cloud sovrano in Francia o in Europa, le opzioni disponibili sono limitate da ciò che questo contesto industriale ha permesso di costruire. Un Paese che non possiede un proprio hyperscaler non può affrontare la stessa discussione sulla sovranità di un Paese che ne possiede uno: gli manca il mattone fondamentale. Ecco perché contrapporre OVH e AWS per trarne conclusioni in materia di sovranità porta a ragionamenti distorti. I due attori non operano nello stesso contesto. Le questioni relative alla dipendenza, alla portabilità e al diritto applicabile non si pongono negli stessi termini a seconda che si consideri un provider di hosting nato da un vincolo di bilancio o un’infrastruttura industriale nata da un progetto di potere, sostenuta da un capitale, da un mercato e da uno Stato che ne volevano una.
La conseguenza è evidente non appena si effettua un confronto. Quando si mettono a confronto OVH e AWS dal punto di vista della «sovranità del cloud», spesso si confrontano due realtà diverse. Le questioni relative alla reversibilità, alla dipendenza e al diritto applicabile non si pongono negli stessi termini a seconda che si affitti un server dedicato o si sottoscriva un collegamento elastico. Su un server dedicato, la reversibilità riguarda soprattutto la portabilità dei propri dati e della propria configurazione. Su una connessione elastica, dipende dal proprio grado di dipendenza da servizi gestiti proprietari, il che rappresenta una questione completamente diversa.
È necessario innanzitutto chiarire di cosa si sta parlando prima di porre la domanda. Definire correttamente l’oggetto in questione, hosting o cloud, non è un semplice dettaglio lessicale: è la condizione necessaria per porre la giusta domanda in materia di sovranità, quella che corrisponde al prodotto che si ha effettivamente tra le mani.
La vera questione non è la bandiera, ma la legge
Ecco il punto che il marketing elude. Un servizio può sfoggiare una bandiera francese, server in Francia, un team a Parigi, e rimanere comunque soggetto alla legislazione di un altro paese. Il CLOUD Act statunitense, approvato nel 2018, autorizza le autorità degli Stati Uniti a richiedere i dati detenuti da un’azienda soggetta alla loro giurisdizione, indipendentemente dal luogo in cui tali dati siano fisicamente archiviati. L’ubicazione non offre protezione. Il collegamento giuridico dell’operatore, sì.
Un cloud sovrano nel senso stretto del termine è un servizio che nessuna legge straniera può raggiungere. Non è un logo. È una proprietà verificabile: a quale giurisdizione è soggetto l’operatore, chi può costringerlo e cosa succede il giorno in cui gli viene interrotto l’accesso.
L’unico indicatore valido
In Francia, un solo indicatore fa fede. La qualifica SecNumCloud, rilasciata dall’ANSSI. La CNIL lo afferma senza mezzi termini: ad oggi è l’unico indicatore che riconosce per qualificare un cloud come sovrano, poiché mira proprio all’impermeabilità alle leggi extraterritoriali. Una qualifica, non una certificazione: un visto di sicurezza, basato sulla dottrina di Stato «Cloud al centro», e successivamente sulla legge SREN, il cui articolo 31 impone ai progetti cloud dello Stato un servizio immune da tali leggi.
La qualificazione rimane l’indicatore riconosciuto dalla CNIL, ma di per sé non garantisce la sovranità: ne costituisce la condizione necessaria, non quella sufficiente. Due ragioni. In primo luogo, l’ambito qualificato potrebbe non coprire l’insieme dei servizi effettivamente utilizzati: un’offerta può essere qualificata a livello di infrastruttura (IaaS) senza esserlo a livello di piattaforma (PaaS), e un’organizzazione che utilizza entrambi copre quindi solo una parte del proprio utilizzo. In secondo luogo, la certificazione non pregiudica né la qualità operativa quotidiana né l’effettiva reversibilità, che può essere verificata solo in caso di effettivo abbandono del servizio. AWS dispone di un’infrastruttura in Francia, ma ad oggi la sua offerta standard non è certificata SecNumCloud: ciò dimostra che la sola localizzazione non è sufficiente e che la certificazione è proprio ciò che la presenza fisica sul territorio non garantisce mai.
L’ecosistema si sta strutturando rapidamente e avanza lungo percorsi sorprendenti. Bleu, promosso da Capgemini e Orange, punta alla qualifica incapsulando le tecnologie Microsoft Azure, isolate dall’infrastruttura globale del gruppo. S3NS, joint venture tra Thales e Google, ha ottenuto la propria certificazione nel dicembre 2025, la prima a coprire infrastruttura e piattaforma in un unico pacchetto. Offerte costruite sulla tecnologia dei giganti che si diceva di voler evitare, chiuse per rispondere ai requisiti di legge. La realtà è più intricata di quanto si pensi. Nel marzo 2026, l’ANSSI e la sua controparte tedesca hanno pubblicato criteri comuni di sovranità, segno che a livello europeo si sta finalmente cercando un punto d’appoggio, dopo anni di stallo sullo schema EUCS.
Dal punto di vista strutturale, S3NS e Bleu rispondono alla stessa equazione. Si tratta di joint venture tra un operatore francese e un hyperscaler statunitense: Capgemini e Orange con Microsoft Azure per Bleu, Thales con Google Cloud per S3NS. Il loro ruolo si riassume in una frase: gestire un’istanza isolata e certificata SecNumCloud dello stack del proprio partner americano. L’involucro è francese, il perimetro è a tenuta stagna, ma il codice, gli algoritmi e i servizi rimangono quelli di Microsoft e Google.
Da qui deriva la tensione fondamentale. La conformità a SecNumCloud risolve il problema giuridico: i dati non escono dal perimetro certificato e si applica il diritto francese senza interferenze da parte di una legislazione straniera. La dipendenza tecnologica e industriale, invece, rimane totale. Se Microsoft o Google interrompessero la tecnologia sottostante, ponessero fine alla partnership o modificassero le proprie condizioni, la sovranità giuridica non garantirebbe la continuità operativa. Non si tratta di un difetto di progettazione di queste offerte: è una tensione strutturale tra due interpretazioni del termine «sovranità» che si tende a confondere.
La domanda posta al dirigente si formula quindi con precisione. La sovranità giuridica e normativa, SecNumCloud e l’immunità dalle leggi extraterritoriali, risponde a una categoria di rischio ben reale. La sovranità industriale, il controllo dello stack e la possibilità di cambiare fornitore senza dover riscrivere tutto da capo, risponde a un’altra categoria, altrettanto reale. Le due non si sostituiscono a vicenda. Un contratto SecNumCloud riduce l’esposizione giuridica: non garantisce né la reversibilità né l’indipendenza tecnologica. Sapere quale delle due si acquista e quale resta da costruire: ecco la decisione da prendere.
Come si risponde oggi
Il dirigente non deve diventare né un giurista né un ingegnere. Deve porre quattro domande ed esigere risposte scritte. A quale ordinamento giuridico è soggetto il contratto? Quali dati vengono trasferiti e dove? Il servizio è qualificato e per quale ambito esatto? Cosa succede se il fornitore scompare o viene interrotto, ovvero la cosiddetta reversibilità?
La sovranità non è il colore di un logo né la nazionalità di un azionista. È un insieme di caratteristiche che vanno verificate punto per punto. Finché si parla di bandiera, si parla di comunicazione. Il giorno in cui si parla di diritto applicabile, qualificazione e reversibilità, si parla finalmente dell’argomento.
Fonti
- ANSSI, qualifica SecNumCloud e dottrina «Cloud al centro», cyber.gouv.fr
- CNIL, intervista sul cloud sovrano, Le Journal des Entreprises, maggio 2026
- Osservatorio SecNumCloud, CyberTaskForce, dicembre 2025
- OVHcloud, cronistoria e risultati dell’esercizio 2025
- CLOUD Act (Stati Uniti, 2018); legge SREN, articolo 31