La crisi del programari comercial: què diuen les dades sobre fer-te'l tu
Un terç de les empreses ja ha substituït alguna eina de pagament per una de pròpia. Les xifres dels dos costats, els biaixos de qui les publica i quan surt a compte.
·14 min de lectura
El terme «crisi del programari» és del 1968. Es va encunyar a Garmisch, en una conferència organitzada per l’OTAN on hi havia Dijkstra, Hoare, Naur i Wirth, i on es va posar nom a un problema que aleshores era nou: el món demanava més programari del que la indústria era capaç de construir. Els projectes arribaven tard, costaven el doble i es trencaven al primer canvi.
Té gràcia que l’expressió aparegui una sola vegada a les actes d’aquella conferència, i de passada, dins d’un incís editorial. La frase va fer molta més fortuna que el diagnòstic.
Cinquanta-vuit anys després tenim la crisi inversa. Construir programari ha deixat de ser el coll d’ampolla. I això, resulta, també és una crisi — només que d’una altra mena.
Què està passant realment
La dada més citada d’aquest any surt de l’informe Build vs. Buy Shift de Retool: el 35 % dels equips ja ha substituït almenys una eina de pagament per una de feta a casa, i el 78 % té previst construir-ne més durant l’any.
El detall interessant no és el percentatge global, sinó què es substitueix:
| Categoria | Equips que l’han substituïda |
|---|---|
| Automatitzacions de flux de treball | 35 % |
| Eines internes d’administració | 33 % |
| Quadres de comandament i BI | 29 % |
I sobretot, què no se substitueix: l’ERP i la comptabilitat de base pràcticament no es toquen. Això no és casualitat i hi tornaré, perquè és la clau de tota la decisió.
Una xifra més del mateix informe, que val la pena tenir present: el 60 % dels enquestats ha construït programari fora de la supervisió del departament de sistemes durant l’últim any.
Abans de seguir: de qui són aquestes dades
Retool ven una plataforma per construir eines internes. Un informe seu que conclou que tothom hauria de construir eines internes no és una font neutral, i s’ha de llegir sabent-ho.
Val el mateix per a la banda contrària. Els informes que diuen que el codi generat per IA és insegur els publica sovint qui ven anàlisi de seguretat. Cap dels dos menteix necessàriament; tots dos trien què mesuren i què destaquen.
La manera de llegir-ho és mirar si les dues bandes, que tenen interessos oposats, coincideixen en alguna cosa. I resulta que sí.
Per què el model comercial trontolla
Hi ha una raó estructural, i no és que el programari de pagament hagi empitjorat. És que la seva manera de cobrar ha deixat de tenir sentit.
El model per usuari es va inventar quan el valor d’una eina era proporcional a quanta gent la feia servir. Quan un agent fa la feina de deu persones, aquesta proporció es trenca: el proveïdor cobra menys precisament quan aporta més, i el client paga per fer-se eficient.
Els proveïdors ho saben. Una enquesta de Cruxy a 300 directius de programari, l’abril del 2026, va trobar que el 97 % té previst abandonar el preu per usuari en dos anys. La proporció d’empreses amb preu purament per usuari ja ha caigut del 21 % al 15 % entre 2025 i 2026, i Gartner preveu que almenys el 40 % de la despesa empresarial en programari passi a models per ús, per agent o per resultat abans del 2030.
Aquesta lectura és important i sovint es fa malament: el programari comercial no s’està morint, s’està reetiquetant. Qui espera que les llicències desapareguin s’equivoca. El que passarà és que la factura deixarà de dependre de quanta gent hi entra i passarà a dependre de quant se’n fa servir — cosa que, segons el cas, pot sortir més cara.
L’estalvi: l’aritmètica que gairebé tothom fa malament
Aquí és on cal ser molt concret, perquè la conversa sol quedar-se a la primera línia del càlcul.
El que es veu: dotze usuaris a 40 € al mes són 5.760 € l’any. Si l’eina la fas tu, aquests 5.760 € desapareixen de la factura. És una xifra real i és satisfactòria de mirar.
El que no es veu: el manteniment comença el dia que l’eina entra en producció i no s’atura mai. Corregir comportaments inesperats. Actualitzar-la quan un sistema connectat canvia de forma. Respondre preguntes de companys. Tornar a formar gent. Investigar excepcions. Revisar permisos. I, al final, jubilar-la.
La descripció que millor ho resumeix la vaig llegir així: el que comença com una construcció de dos dies es converteix en un manteniment de dos anys, amb qui la va fer ja fora de l’equip.
El càlcul honest
Per decidir amb números, la comparació ha de ser a tres anys i ha d’incloure les quatre línies:
| Comprar | Fer-lo | |
|---|---|---|
| Any 0 | implantació + llicència | construcció |
| Anys 1-3 | llicència × 3, amb pujades | manteniment anual |
| Canvis del negoci | inclosos o mòdul de pagament | feina teva, cada cop |
| Canvis de l’entorn | els fa el proveïdor | els fas tu |
Aquesta última fila és la que decideix més casos i la que ningú posa al full de càlcul. Si l’eina toca facturació, nòmines o qualsevol cosa regulada, algú ha de mantenir-la al dia quan canviï la norma. Un proveïdor ho reparteix entre milers de clients. Tu ho pagues sencer.
Que aquest cost és real ho diuen els mateixos que estan construint: als blocatges que citen els equips, la càrrega de manteniment apareix al 26 %, just darrere del retorn poc clar (33 %) i el pressupost (30 %).
La regla que faig servir
Un projecte propi surt a compte quan es compleixen les dues condicions alhora:
- El cost anual de manteniment és clarament inferior a la llicència anual. Si la teva estimació de manteniment és «gairebé zero», l’estimació està malament: com a referència de sector, mantenir sol costar cada any entre el 15 % i el 25 % del que va costar construir.
- Hi ha algú amb nom i cognoms que el mantindrà, i no és qui el va construir en un cap de setmana d’entusiasme.
Si falla la segona, l’estalvi és fictici. El que has fet és convertir una despesa previsible en un risc no comptabilitzat.
Els perills, amb xifres
Aquesta és la part on les dades són més incòmodes, i on convé llegir-les amb la mateixa desconfiança que les de l’altra banda.
El codi generat té un problema de seguretat mesurable
L’informe de Veracode de la primavera del 2026 dona una dissociació que val la pena entendre bé:
- Correcció sintàctica: per sobre del 95 %. El codi compila i funciona.
- Aprovació en seguretat: al voltant del 55 %. Gairebé la meitat de les mostres contenen vulnerabilitats conegudes quan no s’ha donat cap indicació de seguretat.
En proves concretes, el 86 % de les mostres no es defensava d’un atac de guió creuat i el 88 % era vulnerable a injecció al registre.
Aquesta dissociació és exactament el que fa el problema perillós: el codi funciona. No hi ha cap senyal visible que digui que hi ha un forat. Una persona sense formació en seguretat que provi l’eina i vegi que fa el que ha de fer, conclourà raonablement que està bé.
El volum acompanya: el codi generat per IA ja és el 41 % del codi nou escrit el 2026 i introdueix 1,7 vegades més incidències que el codi humà, amb més de 10.000 troballes de seguretat noves cada mes — deu vegades més que a finals del 2024. El 82 % de les organitzacions diu estar desbordat pel deute de seguretat, onze punts més que l’any anterior.
Recordatori del biaix: això ho publica qui ven anàlisi de seguretat. Però l’ordre de magnitud el corroboren estudis acadèmics independents, i el mecanisme és versemblant sense necessitat de creure ningú.
La productivitat no és la que sembla
Aquest és el resultat que més m’ha fet pensar. En un estudi de METR amb setze desenvolupadors experimentats treballant en tasques reals dels seus propis repositoris, els que feien servir IA van trigar un 19 % més — i van declarar que s’havien sentit un 20 % més ràpids.
L’important no és el 19 %. És la distància de gairebé quaranta punts entre la sensació i el resultat. Vol dir que la percepció d’anar ràpid no és evidència de res, i que qualsevol decisió de «fem-ho nosaltres que és més ràpid» basada en com se sent l’equip està construïda sobre sorra.
Els indicadors de lliurament apunten en la mateixa direcció: amb una adopció al voltant del 93 %, els guanys de productivitat organitzativa es queden a la vora del 10 %, mentre pugen els errors i el temps de revisió i baixa l’estabilitat.
I la previsió que hauria de moderar qualsevol entusiasme: Gartner calcula que més del 40 % dels projectes d’IA agèntica s’hauran cancel·lat abans que acabi el 2027, per costos que s’esbaten, valor poc clar i controls de risc insuficients.
El risc de la persona única
Aquest no surt als informes i és el que veig més sovint.
Una eina interna feta per una persona és, en la pràctica, propietat d’aquella persona. Quan canvia d’equip, plega o simplement està de vacances la setmana que l’eina falla, l’empresa descobreix que depèn d’un programari que ningú entén, sense documentació, sense proves i sense ningú a qui trucar.
Amb un proveïdor comercial tens un contracte i un telèfon. Amb l’eina de casa tens un fitxer i una esperança.
El programari a l’ombra
El 60 % que construeix fora de la supervisió de sistemes té una conseqüència que arriba tard i cara. Una eina que ningú ha inventariat no entra a cap auditoria, no es té en compte a cap anàlisi de riscos i no apareix a cap registre de tractament de dades — fins que un regulador la troba.
Amb el Reglament d’IA europeu ja en aplicació i el RGPD de sempre, una eina interna que tracti dades personals i que ningú hagi declarat ja és un incompliment, encara que funcioni perfectament.
Hi ha, això sí, una dada esperançadora: quan l’organització ofereix eines aprovades, l’ús no autoritzat cau un 89 %. La resposta a l’ombra no és prohibir; és donar un camí oficial que sigui igual de còmode.
Quan comprar i quan fer-lo
Aquí és on tot això s’ha de convertir en una decisió. Els criteris que faig servir:
Compra quan
- És una mercaderia. Comptabilitat, nòmines, factura electrònica, correu. No hi ha cap avantatge competitiu a fer la teva pròpia comptabilitat, i sí molt risc.
- La norma canvia i no la controles tu. Fiscalitat, laboral, facturació. Que el proveïdor mantingui això al dia val cada euro que costa.
- La certificació és part del producte. Si necessites ISO 27001, ENS o un informe SOC 2 per vendre, comprar-ho és molt més barat que aconseguir-ho.
- Ho necessites la setmana que ve. Una eina de pagament arrenca avui. La teva, no.
- És un problema resolt per molta gent. Un gestor de tiquets ben fet ha vist deu mil casos límit que tu encara no has imaginat.
Fes-lo quan
- És el que et diferencia. El procés que fas diferent de la competència no el trobaràs en cap catàleg. Precisament perquè és teu.
- Pagues cent funcions per fer-ne servir sis. És el cas més freqüent i el més fàcil de justificar amb números.
- La feina de veritat és la integració. Quan el valor no és l’eina sinó connectar-la amb el que ja tens, la part comprada aporta poc i l’engany surt car.
- El preu per usuari et castiga per créixer. Si cada persona nova o cada client nou multiplica la factura sense multiplicar el valor, el model no encaixa amb el teu negoci.
- És petit, acotat i el pot sostenir una persona. Aquest és el terreny on el 35 % de l’informe té tota la raó: automatitzacions i eines internes d’administració són exactament això.
La frontera, en una frase
L’informe ho diu sense voler amb les seves pròpies dades: se substitueixen automatitzacions i eines internes; no se substitueix l’ERP. La frontera no és la mida de l’empresa ni el pressupost. És aquesta:
Construeix el que has de canviar sovint perquè és teu. Compra el que ha d’estar sempre correcte perquè el defineix algú altre.
Les cinc preguntes abans de començar
Si després de tot això la resposta és construir, aquestes cinc han de tenir resposta abans de la primera línia de codi. No són burocràcia: són les que separen un projecte que aguanta d’un que serà un problema d’aquí a divuit mesos.
- Qui el manté d’aquí a dos anys? Amb nom, i havent-ho parlat amb aquesta persona.
- Què passa el dia que es trenqui i aquesta persona no hi sigui? Si la resposta és «doncs esperem», ja saps el cost real de la indisponibilitat.
- Hi ha una especificació, o només un historial de conversa? El que no està escrit en un document no existeix. És exactament el problema del desenvolupament dirigit per especificació, i aquí es paga en producció.
- Qui ha revisat la seguretat del que ha escrit el model? Vist el 55 % d’aprovació, «ningú» no és una resposta acceptable per a res que toqui dades de persones o diners.
- Com se surt d’aquí? Si demà l’eina s’ha d’abandonar, les dades han de poder sortir. Aquesta pregunta se li fa sempre als proveïdors i gairebé mai a un mateix.
El camí del mig, i el meu conflicte d’interessos
He de dir una cosa abans de la conclusió: jo em guanyo la vida construint aquestes coses. Un article que conclogués «feu-vos-ho tot vosaltres» seria sospitosament convenient per a mi. Llegeix el que ve a continuació sabent-ho, igual que has llegit les dades de Retool i les de Veracode.
Dit això, la conclusió que em surt de les xifres no és cap dels dos extrems, i és la que aplico als projectes:
Compra la mercaderia. Construeix l’enganxament.
L’ERP, la comptabilitat i el correu, de proveïdor. El que connecta l’ERP amb la botiga, el que ordena les dades entre sistemes i el que automatitza el procés que fas diferent de tothom, propi. Aquesta capa intermèdia és petita, és teva, canvia sovint i no existeix cap producte que la vengui — perquè és la forma concreta de la teva empresa.
És també la capa on el risc és més fàcil de contenir: si una automatització falla, s’atura un procés; si falla el sistema de facturació, s’atura l’empresa.
Tornant al 1968
Aquella conferència no va concloure que calgués escriure codi més ràpid. Va concloure que el problema era tot el que ve després: que els sistemes són grans, que canvien, que ningú els entén sencers i que el cost de mantenir-los supera de llarg el de fer-los.
Res d’això ha canviat. L’única cosa que ha canviat és que ara el principi és gairebé gratis, i això fa molt més fàcil començar coses que després no se sap qui sostindrà.
La crisi del programari no era mai una crisi de construcció. Era, i continua sent, una crisi de manteniment. La diferència és que abans això només afectava els que sabien programar, i ara afecta tothom.
Fonts principals: Retool, Build vs. Buy Shift Report 2026 · Veracode, GenAI Code Security Update, primavera 2026 · CIO, The SaaS reckoning: why AI is about to reprice enterprise software · Cloud Security Alliance, nota de recerca sobre codi generat per IA · Actes de la conferència de l’OTAN, Garmisch 1968 · l’estudi de METR sobre productivitat, l’enquesta de Cruxy a directius de programari i les previsions de Gartner, citats aquí a través de les fonts anteriors i no consultats en original.