Nel contenzioso informatico “latente” la scintilla è spesso minuscola. Un requisito scritto male, un collaudo indefinito, una promessa di assistenza senza livelli di servizio. Poi arriva il fermo macchina, o l’ennesima consegna slittata, e la controversia si materializza.
Il contratto di sviluppo software si colloca, di regola, nell’orbita dei contratti ad oggetto informatico e “vive” di allegati: analisi dei requisiti, piano di lavoro, procedure di accettazione, manutenzione. La difficoltà sta qui. L’assenza di disciplina specifica impone rigore redazionale e coerenza tecnica.
Già in passato, su questo portale, ci siamo soffermati più volte su questo genere di contratti ed anche su quelle che sono le principali criticità che si riscontrano comunemente (premere qui per approfondire). Scopo del presente contributo è invece quello di elencare quelli che sono gli errori più frequenti che trasformano un progetto in un contenzioso.
Una premessa di metodo doverosa. Il taglio del presente contributo è squisitamente pratico, e volutamente “chirurgico”, pensato più come una piccola guida che come un articolo di approfondimento.
Errore 1 — Requisiti vaghi: il “Piano di Lavoro” come zona grigia
Molte liti nascono prima della prima riga di codice. Nascono cioè quando gli obiettivi restano impliciti.
Nella prassi, si insiste troppo poco sul fatto che la scarsa chiarezza nella definizione di obiettivi e aspetti tecnici costituisce spesso causa di contestazioni in corso d’esecuzione. Il Piano di Lavoro serve proprio a “misurare” la prestazione e il risultato dovuto.
Scrivere “gestionale intuitivo e veloce” non basta. Occorre indicare, ad esempio, tempi di risposta, tolleranze, carichi, vincoli di interoperabilità e ambiente hardware/software di destinazione.
Quando manca questa metrica, la parte insoddisfatta tenderà a qualificare ogni difformità come inadempimento. L’altra parte parlerà di “aspettative”.
Errore 2 — Confondere obbligazione di risultato e obbligazione di mezzi
La qualificazione giuridica non è un vezzo accademico. Incide sul criterio di adempimento.
In particolare, il contratto può avvicinarsi al contratto di appalto o al contratto d’opera. In alcuni casi, se il prestatore è un professionista intellettuale, può rilevare la disciplina dell’opera intellettuale. Ne deriva la dialettica (non sempre netta) tra obbligazione di risultato e obbligazione di mezzi.
Se non si governa questa ambivalenza in clausole chiare, la lite diventa una disputa di qualificazioni. E il progetto resta sul tavolo del giudice.
Errore 3 — Collaudo “folkloristico”: accettazione, riserve e decadenze
Il collaudo è il varco. Da lì passano pagamento, responsabilità e garanzie.
In un contratto di sviluppo software solido, la verifica finale (collaudo) deve prevedere alternative nette: accettazione senza riserva, accettazione con riserva, rifiuto con richiesta di nuovo test. Se il committente non collauda ingiustificatamente o non denuncia vizi/difetti nei termini, il software può intendersi accettato, con effetti importanti anche sul piano delle garanzie.
Questa logica dialoga con la disciplina codicistica: in base a quanto stabilito infatti dall’art. 1665 c.c. il committente ha diritto di verificare l’opera e deve farlo quando l’appaltatore lo mette in condizione di eseguirla (premere qui per leggere).
E, soprattutto, ai sensi dell’art. 1667 c.c., la denuncia dei vizi va gestita con attenzione perché la decadenza è dietro l’angolo (premere qui per leggere).
Errore tipico: “collaudo entro 30 giorni” senza definire test, criteri di superamento, classi di difetto e procedura di ripetizione. Nel software, il collaudo non è solo “funziona/non funziona”, è anche (e soprattutto) interazione con sistemi terzi e ambienti reali.
Errore 4 — SLA assenti: manutenzione promessa, ma non esigibile
L’assistenza non si improvvisa. Si governa.
Molti contratti parlano di “manutenzione inclusa” ma omettono i parametri essenziali: tempi di presa in carico, tempi di ripristino, modalità (da remoto o on-site), finestre operative, severità dei ticket, esclusioni.
In un contratto di sviluppo software solido, la clausola di garanzia/manutenzione può prevedere, ad esempio, un termine in ore lavorative per la constatazione del problema e l’obbligo di eliminare le difformità rispetto alle specifiche, con collegamento esplicito ai rimedi previsti dalla disciplina dell’appalto ex art. 1668 c.c. (premere qui per leggere).
Sul piano civilistico, infatti, il committente può chiedere eliminazione dei vizi a spese dell’appaltatore o riduzione del prezzo, oltre al risarcimento del danno in caso di colpa e, nei casi più gravi, la risoluzione del rapporto contrattuale.
Senza SLA (Service Level Agreement) ossia senza quelle clausole contrattuali – o allegati contrattuali – che definiscono in modo oggettivo, misurabile ed esigibile il livello di servizio che il fornitore si impegna a garantire dopo la consegna del software, la pretesa si trasforma in retorica. E la retorica non regge in causa.
Errore 5 — Proprietà del codice sorgente: dare per scontata la cessione
Questo è l’errore più esplosivo. Ed è frequente.
Va subito evidenziato infatti che il trasferimento del codice sorgente non è affatto scontato: il fornitore può volerlo trattenere per riuso futuro. Dall’altra parte, senza sorgente il committente rischia di non poter manutentare il software, specie se il fornitore cessa l’attività.
Le opzioni pratiche ricorrenti sono molte: consegna del solo codice oggetto con licenza d’uso, consegna del sorgente con limiti di circolazione, fino alla soluzione di compromesso del deposito in escrow (deposito in garanzia) che consente il rilascio al committente in caso di fallimento o cessazione del fornitore.
Qui si innesta anche il diritto d’autore sui programmi per elaboratori elettronici. La normativa riconosce infatti diritti esclusivi (tra cui riproduzione e modificazione) e disciplina espressamente i programmi per elaboratore.
Traduzione operativa: senza una clausola ben scritta su titolarità e licenza, si litigano usi consentiti, derivati, riutilizzo di componenti, portabilità.
Errore 6 — Change request senza governo: extra-costi e ritardi “incontrollati”
Ogni progetto evolve. Il contratto deve prevederlanca una clausola di variazione del Piano di Lavoro, la modifica entra dalla finestra. Poi entra la fattura extra. Infine entra la contestazione.
La prassi più prudente separa: ciò che è incluso nelle specifiche iniziali, ciò che è variazione, e come si autorizza la variazione (ordine scritto, stima tempi/costi, impatto su milestone e collaudi). Andrebbe sempre valutata poi anche l’opportunità di inserire allegati ulteriori, quali l’accordo di manutenzione, il deposito del sorgente, e le tabelle costi (time & material).
Errore 7 — Penali e rimedi scritti male: o troppo deboli o troppo aggressivi
La penale deve essere un deterrente, non un boomerang.
In un solido contratto di sviluppo software dovrebbe essere sempre prevista una penale per ritardata riconsegna parametrata ai giorni di ritardo e alla durata della prestazione, nonché una penale per collaudo negativo (con logica di riassorbimento).
Ma attenzione. Se la penale è sproporzionata, diventa ovviamente terreno di attacco. Se è simbolica, invece, non serve. Se è scollegata da collaudo e milestone, genera invece calcoli incongrui e contestazioni seriali.
Come Intercettare il contenzioso prima che esploda
Il contenzioso “latente” si riconosce da segnali ripetitivi quali, ad esempio e-mail su “non era previsto”, ticket senza risposta, consegne parziali non formalizzate, test improvvisati, richieste di sorgente a progetto finito.
In questa fase, una revisione contrattuale mirata costa poco. E salva molto.
In ogni contratto di sviluppo software è imprescindibile quindi presidiare, in modo sistematico, alcuni snodi negoziali che costituiscono il principale bacino di contenzioso latente. In primo luogo, la titolarità e la licenza del codice, con particolare riguardo al codice sorgente, alle facoltà di modifica, riuso e manutenzione evolutiva. In secondo luogo, la disciplina delle SLA e della manutenzione, che deve tradurre l’assistenza tecnica in obbligazioni temporalmente determinate e giuridicamente esigibili. Non meno rilevante è il governo delle change request, attraverso procedure formali di approvazione delle varianti e di ridefinizione di tempi e corrispettivi, al fine di evitare extraprestazioni incontrollate. Infine, le penali, che devono essere coerenti con milestone, collaudi e livelli di servizio, così da svolgere una funzione realmente deterrente senza degenerare in clausole sproporzionate o facilmente contestabili.
Se state negoziando un contratto di sviluppo software, oppure se il progetto è già in corso e manifesta segnali di frizione, fidatevi, la soluzione più razionale è una revisione contrattuale mirata. Un intervento tempestivo consente di riallineare titolarità e disponibilità del codice sorgente, SLA e obblighi di manutenzione, Piano di Lavoro, procedure di collaudo e meccanismi di gestione delle variazioni, riducendo in modo significativo il rischio di contenzioso futuro.
Una clausola corretta oggi evita una citazione domani.
Per approfondire:
- G. FINOCCHIARO, I contratti informatici, Padova, 1997;
- G. ALPA, V. ZENO ZENCOVICH (a cura di), I contratti di informatica, Milano, 1987;
- W. ROYCE, Managing the development of large software systems, in Proceedings of IEEE WESCON, 26.1, 1970. pp. 1-9;
- C. ROSSELLO, I contratti dell'informatica nella nuova disciplina del software, Milano, 1997;
- R. ZALLONE, Informatica e telematica: i nuovi contratti di servizi, Milano, 2003;
- I. IASELLI, I contratti informatici, Roma, 2003;
- P. DI SALVATORE, I contratti informatici, Napoli, 2000;
- B. MUSTI, I contratti a oggetto informatico, Milano, 2008;
- G. ALPA, Responsabilità extracontrattuale ed elaboratore elettronico, in Diritto dell’informazione e informatica, 1986, p. 387 e ss.;
- V. APRUZZI, Il contratto di escrow: aspetti giuridici, in Ciberspazio e diritto, 2002, p. 79 e ss.;
- A. ZINCONE, Come prevenire le problematiche inerenti all’utilizzazione del software, in Diritto d’Autore, 1993, p. 380 e ss.
Nicola Nappi
Ultimi post di Nicola Nappi (vedi tutti)
- E-commerce: gli obblighi legali decisivi - 30 Marzo 2026
- Videosorveglianza sul lavoro: gli errori che costano caro - 23 Marzo 2026
- Il DPO esterno nelle PMI - 16 Marzo 2026
- Data breach: cosa fare nelle prime 72 ore - 9 Marzo 2026
- Privacy e imprese: il problema non è il regolamento - 2 Marzo 2026
