Prima puntata della Perizia nuova rubrica di Linea Edp realizzata da Roberto Bello, consulente del Tribunale di Milano
Molto spesso non ci si immagina di diventare protagonisti, come attori o convenuti, in cause legali per applicazioni Ict, dove una parte lamenta errori, disfunzioni, anomalie e carenze in un’applicazione, mentre l’altra si difende con considerazioni opposte tese a dimostrare le adeguate funzionalità e il rispetto di quanto contrattualmente pattuito.
Ipotizziamo che un’azienda voglia acquistare da una software house la licenza d’uso di un applicativo gestionale e chieda poi delle personalizzazioni. Molto probabilmente, il fornitore farà sottoscrivere al cliente un primo contratto relativo alla cessione della licenza d’uso nella sua forma standard con un’appendice ove si descrivono le modalità dei futuri aggiornamenti, indicando i canoni di manutenzione ordinaria.
Un ulteriore contratto, più o meno dettagliato, potrebbe essere sottoscritto per le personalizzazioni e dovrebbe contenerne la descrizione, i tempi di realizzazione, le risorse stimate (giorni uomo per tipologia professionale) e le date previste di rilascio delle diverse funzionalità aggiunte o da modificare. Più frequentemente, il fornitore fa sottoscrivere una paginetta ove le parti prendono atto del valore in euro delle tariffe giornaliere delle figure professionali del fornitore coinvolte nelle attività di personalizzazione. La logica implicita sottostante sottintende che il cliente può chiedere quello che vuole, il fornitore lo esegue e il cliente paga il tempo consumato, indipendentemente dal risultato.
Interventi inizialmente stimati dal cliente come facili e poco impegnativi risultano poi costosi e complicati per il fornitore. Alle volte anche gli errori trovati dal cliente in parti standard dell’applicazione, per il fornitore sono la conseguenza delle personalizzazioni volute dal cliente e, a suo parere, il costo della loro sistemazione deve essere a totale carico del cliente.
Così comincia l’intrecciarsi di telefonate, e-mail, raccomandate, diffide ad adempiere, fino alla notifica a comparire davanti al giudice per la costituzione in giudizio delle parti, ormai in aperta lite.
Il ruolo del Ctu
La causa inizia il suo iter e dopo circa quattro o cinque anni di udienze consumate a esaminare carte, chiedere rinvii, eccepire vizi procedurali, ascoltare testimoni, il giudice assegna un quesito (o dei quesiti) a un consulente tecnico d’ufficio (Ctu) che deve, in circa sessanta giorni, scoprire se l’applicazione di cinque anni prima funzionava o meno. Ma in cinque anni quanta acqua è passata sotto i ponti della tecnologia? Spesso i computer di allora non esistono più e neppure i programmi. Oppure i programmi sono su un Cd del fornitore che giura contengano proprio i programmi di allora, mentre potrebbe essere stato confezionato il giorno precedente con una versione dell’applicazione abilmente aggiornata ed esente dai vizi allora lamentati.
Peggio ancora quando l’applicazione riguarda un sito Web di tipo dinamico. Il Ctu ha il dovere di effettuare una valutazione di tipo tecnico su archivi e sistemi Ict riferibili ai tempi di inizio della lite, archivi e sistemi che non possano essere contestati dai consulenti tecnici di parte (Ctp) perché non rappresentativi di quanto in contestazione. Una massima della Corte di Cassazione Sezione Lavoro n. 2912 del 18 febbraio 2004 in relazione al valore probatorio di una pagina Web indica che “la copia di una pagina Web su supporto cartaceo ha valore probatorio solo se raccolta con le dovute garanzie per la rispondenza all’originale e la riferibilità a un momento ben individuato. Le informazioni tratte da una rete telematica sono per loro natura volatili e suscettibili di continua trasformazione”.
Gli archivi memorizzati su supporti magnetici sono, per loro natura, facilmente manipolabili; le versioni precedenti degli archivi scompaiono in modo totale e, a differenza di ciò che accade nel mondo del reale, non restano tracce della loro precedente identità.
Precauzioni necessarie
Per prepararsi quindi al meglio, in vista di possibili liti future, occorre osservare delle precauzioni di tipo contrattuale e altre di tipo tecnico-organizzativo.
Sono molto importanti i contenuti del contratto iniziale di fornitura, soprattutto per quanto riguarda il dettaglio delle personalizzazioni, i tempi di realizzazione e quelli di risposta, i risultati attesi, gli utenti che possono operare contemporaneamente, la disponibilità del codice sorgente, i requisiti minimi di hardware e di software, gli obblighi e le penali in caso di malfunzionamento, le garanzie di operabilità su altri sistemi, i livelli di formazione richiesti agli utenti e quant’altro i soggetti contrattuali ritengano necessario per definire le prestazioni di una parte verso l’altra.
Sono, sicuramente, da evitare contratti per la personalizzazione di un’applicazione che tengano conto come termine di misura solo il tempo speso per realizzare quanto il cliente desidera: il fornitore sarebbe troppo tentato nel seguire i desideri più strani e destabilizzanti (per l’applicazione); interventi dannosi che comunque procurerebbero fatturato al fornitore senza alcuna sua responsabilità.
Nella mia esperienza di Ctu, ho verificato che l’aspetto contrattuale è sì considerato ma non con il dettaglio tecnico necessario a una futura perizia. Nel corso della stipulazione, le parti dovrebbero procurarsi delle prove valide da utilizzare in caso di eventuale contenzioso.
Quando avviene la consegna dell’applicazione, ad esempio, è opportuno che cliente e fornitore diano atto dell’installazione avvenuta, apponendo anche la firma e la data di installazione (con pennarello a inchiostro indelebile) su copie identiche di cd contenenti i programmi eseguibili, gli eventuali sorgenti, i manuali di installazione e di uso, le specifiche tecniche e così via. Tali copie potranno servire in sede di contenzioso e la loro autenticità non potrà essere messa in dubbio poiché, non alterabili, datate e sottoscritte da entrambe le parti.
Può succedere, poi, che il cliente lamenti errori e malfunzionamenti dell’applicazione che il fornitore non riconosce. In questo caso, mancando la collaborazione, è opportuno rivolgersi a un perito, meglio se iscritto all’albo del Tribunale, e incaricarlo di una perizia giurata. Svolto l’incarico, il perito prepara l’elaborato, allega a esso il cd (datato e firmato) contenente i programmi, i dati e quant’altro necessario per documentare gli errori riscontrati, si reca in Tribunale e giura di aver svolto la perizia presso il cliente nella data certa riportata nell’elaborato stesso.
Il documento peritale costituisce un altro esempio di prova precostituita. Risultato analogo si otterrebbe depositando il cd presso un notaio che, senza entrare nel merito tecnico del contenuto, potrebbe certificarne la data di deposito.
In alternativa alla Ctu è disponibile un altro procedimento previsto dall’art. 696bis c.p.c. (Accertamento tecnico preventivo) che con tempi molto rapidi può intervenire su sistemi, programmi e reti di comunicazione ancora attuali.
Il consiglio principale, comunque, resta quello di andare in causa solo se si è in grado di produrre prove tecniche sicure e non contestabili, a meno che il fine effettivo sia di tirare per le lunghe il procedimento, usando i tempi della giustizia per non pagare. E purtroppo succede spesso.
L’Esperto
Roberto Bello è perito estimatore e Ctu (codice 7890) presso il Tribunale di Milano per quanto riguarda il software e consulente per la preparazione del Dps (Documento programmatico sulla sicurezza). Esperto nel settore delle applicazioni e dell’ambiente open source, è socio fondatore dell’Associazione Italiana Professionale di Informatica, nonché consigliere e Ict Strategist del ClubTi di Milano.
