Qualche giorno fa siamo stati al WMF2026, a Bologna. È un periodo in cui di intelligenza artificiale parlano tutti, e costruire un software o un sito non è mai stato così rapido: gli strumenti, AI compresa, fanno una buona parte del lavoro. La domanda che ci portavamo dietro era un'altra: quanti, davvero, lo fanno con cura? Abbiamo parlato con diverse aziende. Prodotti validi, idee buone, persone in gamba. Con una di loro, a fine giornata, il discorso si è aperto, e ci siamo lasciati così: «provate la nostra piattaforma e diteci cosa ne pensate».
La sera stessa abbiamo guardato con calma due cose. La prima è il loro sito aziendale, che è il primo posto in cui si arriva. La seconda è la piattaforma che ci avevano proposto, la loro idea migliore. Non per cercare il pelo nell'uovo, ma per curiosità, e perché un occhio esterno a volte vede ciò a cui chi costruisce si è ormai abituato.
Quello che abbiamo trovato (e che capita a tutti)
Il sito era fatto bene: testi curati, struttura chiara, niente fronzoli. La piattaforma, idem: un'idea valida e ben presentata. Eppure, guardando sotto la superficie, sono uscite alcune cose. Nessuna è un errore «da incompetenti»: sono cose che sfuggono quando si va veloci, e che possono sfuggire anche a noi. Le raccontiamo come categorie di problema, non come ricetta, perché il punto non è il caso singolo, è imparare a riconoscerle. Partiamo dal sito.
Un banner del consenso che non bloccava niente
C'era il banner dei cookie, con i suoi pulsanti. Ma gli script di analisi partivano comunque, prima che l'utente scegliesse. Il banner c'era, il blocco no. È una delle cose più frequenti che si vedono in giro, perché «mettere il banner» sembra la parte difficile, mentre quella vera è bloccare davvero il tracciamento finché il consenso non arriva. Sul perché un banner di facciata non basta a essere a norma, la nostra cookie policy è scritta proprio con questo criterio: niente tracciamento prima del sì.
Link che portavano all'ambiente di prova
Sempre sul sito, alcuni link in produzione puntavano all'ambiente di staging: la copia di lavoro dove si prova tutto prima di pubblicare. Capita quando si copia e incolla in fretta, o quando una build si porta dietro un indirizzo che andava cambiato. Da fuori sembra un dettaglio. In pratica espone una parte del lavoro che doveva restare interna, e confonde chi naviga: due versioni dello stesso sito, e nessuna indicazione di quale sia quella vera.
Dati che non si vedevano, ma si potevano raggiungere
Passiamo alla piattaforma. Analizzandola con calma, ci siamo accorti che alcuni dati personali (nome, cognome, email) non comparivano nell'interfaccia, ma erano comunque raggiungibili in pochi minuti da chi ha un minimo di dimestichezza tecnica, su un portale pubblico. «Non si vede» non vuol dire «non c'è»: nascondere un dato nella schermata è un'altra cosa rispetto a proteggerlo. Non scriviamo come ci si arrivava, e non serve saperlo: la categoria di problema è questa, dati reali a portata di chi non dovrebbe vederli, dati che qualcuno avrebbe potuto raccogliere e usare per conto proprio. È la più seria, perché tocca persone vere.
Dati datati, e un controllo saltato
Sempre sulla piattaforma, un'altra cosa salta all'occhio: buona parte dei dati che mostra è palesemente datata, ferma a tempo fa. Non è un problema di grafica, è il segno di un passaggio saltato. Quando si portano dentro dati da un'altra fonte, il primo lavoro non è spostarli, è controllarli: la qualità del dato. Integrare senza verificare vuol dire trascinare in produzione dati vecchi o sbagliati, e poi prenderci sopra decisioni. È il passaggio che nella integrazione dati viene prima del trasferimento: prima si controlla quello che si sposta, poi lo si sposta.
Perché succede, e perché può succedere a chiunque
Non è una questione di bravura. Gli strumenti di oggi rendono facile arrivare a qualcosa che funziona e sembra finito. La parte che non si è automatizzata è il dubbio: fermarsi e chiedersi «e se questo dato fosse raggiungibile da fuori? e se questo link finisse online così com'è?». Il primo controllo non è il codice, è il pensiero critico di chi costruisce. Gli stessi strumenti che ci fanno andare veloci non hanno paura di niente: non sanno quali dei tuoi dati sono sensibili, né cosa succede a valle. Quella consapevolezza la porta chi conosce il problema e risponde del risultato.
La differenza tra una demo e la produzione
Una demo deve convincere: mostra l'idea, e va benissimo che sotto sia un guscio. La produzione ha dentro persone vere, dati veri, conseguenze vere. Lo stesso schermo, in demo è una promessa, in produzione è una responsabilità. E quando apri un portale pubblico, chiunque può guardarci dentro: quei dettagli che in demo non si notano diventano la porta da cui passano i problemi. Il sogno di una piattaforma, lì, può trasformarsi in fretta nel suo contrario.
Gliel'abbiamo detto di persona, e ci hanno ringraziato
Il giorno dopo siamo tornati da loro, in fiera, per continuare il discorso, e gliel'abbiamo detto di persona. Non per fare i bravi, e non per vendere niente: perché è quello che si fa. Ci hanno ringraziato, ed erano contenti della segnalazione. È andata come deve andare: chi si accorge lo dice, chi riceve sistema. Non «guardate come sbagliano gli altri»: anche a noi sfugge qualcosa, e ci farebbe piacere che qualcuno ce lo dicesse allo stesso modo. Fare le cose bene è una responsabilità condivisa di chi le costruisce, non un voto in pagella.
Una checklist prima di andare in produzione
Nessuna di queste domande richiede di essere esperti. Richiede di non spegnere il dubbio quando lo strumento dice che è tutto pronto.
- Il consenso ai cookie blocca davvero analytics e tracciamento finché l'utente non accetta? Il banner, da solo, non basta.
- Tutti i link e gli indirizzi puntano alla produzione, e non all'ambiente di prova?
- I dati personali sono protetti a monte, sul chi-può-accedere-a-cosa, e non solo nascosti nell'interfaccia?
- Se hai importato dati da un'altra fonte, qualcuno ne ha controllato qualità e aggiornamento prima di portarli in produzione?
- Per un portale pubblico, qualcuno che non ha costruito quella parte ha provato a guardarci dentro con occhi diversi?
- Esiste un momento, prima del lancio, in cui si controlla con calma quello che si sta per pubblicare?
Costruire in fretta è facile. Costruire bene è una scelta.
Gli strumenti hanno abbassato la barriera: arrivare a qualcosa che gira è alla portata di tutti. Farlo bene, invece, è ancora una scelta, e si vede nei dettagli che nessuno noterà finché non vanno storti. È lo stesso metodo con cui lavoriamo, su un sito come su un software gestionale: prima capire, poi costruire, e prima di pubblicare guardare due volte. Se volete, diamo un'occhiata al vostro sito o alla vostra applicazione e vi mandiamo un report, senza impegno: a volte basta un occhio esterno, prima o dopo aver pubblicato, per accorgersi di ciò a cui ci si è fatti l'abitudine. Raccontateci come lavorate.