En un proyecto web, la mayoría de los conflictos no nacen de un fallo técnico, sino de un desacuerdo sobre lo que se había prometido. Un contrato claro no sirve para ganar un juicio: sirve para no llegar a él. Estas son las cláusulas que, en un encargo de desarrollo o diseño, evitan que la ambigüedad de hoy se convierta en el conflicto de mañana.
Definir el alcance y, sobre todo, sus límites
La primera fuente de tensión es el alcance. Un presupuesto que enumera funcionalidades sin decir dónde terminan deja la puerta abierta a la ampliación silenciosa: la famosa «pequeña petición extra» que, repetida, se come el margen. La cláusula de alcance describe los entregables esperados, pero también nombra las exclusiones y las hipótesis de trabajo: la versión del CMS previsto, los contenidos aportados por el cliente, los navegadores admitidos.
Todo lo que salga de ese marco pasa por un anexo: escrito, presupuestado y firmado antes de ejecutarlo. No tiene nada de burocrático: convierte una negociación tensa al final del proyecto («pero yo pensaba que estaba incluido») en una decisión explícita tomada en el momento adecuado. El contrato gana al distinguir los entregables de los simples medios y al detallar la aceptación: cuántas rondas de revisión, en qué plazo valida el cliente, qué ocurre si no hay respuesta.
El pago: anticipo, hitos y reserva de propiedad
Un proyecto web rara vez se paga de una sola vez. El anticipo al encargo —a menudo entre el treinta y el cuarenta por ciento— compromete al cliente y cubre la puesta en marcha. El resto se reparte en hitos ligados a entregables concretos, no a fechas arbitrarias. Vincular un pago a una fase de aceptación en lugar de al día 15 del mes evita financiar de tu bolsillo la lentitud de un cliente.
Dos cláusulas completan el dispositivo. Las penalizaciones por demora en el pago recuerdan que el crédito al proveedor no es gratis. La cláusula de reserva de propiedad establece que los entregables siguen siendo propiedad del prestador hasta el pago íntegro: mientras la factura no esté saldada, ni la cesión de derechos ni la puesta en producción han tenido lugar.
Un presupuesto firmado vale como contrato, pero calla sobre los puntos espinosos: ahí es justamente donde se alojan los litigios.
La propiedad intelectual: quién posee qué
El código y las creaciones no se transfieren automáticamente al cliente por el hecho de pagar. En derecho francés, la cesión de derechos de autor debe ser escrita y delimitada: qué derechos, para qué soportes, qué territorio, qué duración. Un contrato web serio distingue tres capas. El trabajo a medida producido para el encargo se cede al cliente, por lo general al pago íntegro. Los bloques reutilizables del prestador —una base de componentes, una librería interna— siguen siendo suyos y se conceden bajo licencia de uso. Las dependencias de terceros conservan sus propias licencias de código abierto, que conviene mencionar en el contrato para que no haya ambigüedad sobre lo que el cliente puede redistribuir.
La misma lógica se aplica a los visuales, las tipografías y los contenidos: una imagen con licencia para un sitio web no lo está necesariamente para una aplicación móvil derivada. Nombrar esos límites protege al cliente tanto como al prestador, que no tiene interés alguno en ceder derechos que no posee.
Responsabilidad, datos y reversibilidad
Ningún prestador serio promete un software sin defectos. La cláusula de limitación de responsabilidad fija un tope a la indemnización, a menudo el importe del encargo, y excluye los daños indirectos como el lucro cesante. Va de la mano de una definición honesta de las garantías: corregir anomalías durante un periodo de garantía es una cosa; el mantenimiento evolutivo es otra, y corresponde a un contrato aparte.
Dos temas merecen cláusula propia. El primero es la protección de datos: en cuanto el prestador trata datos personales por cuenta del cliente, el RGPD exige un contrato de encargo de tratamiento que fije las obligaciones de cada parte. El segundo es la reversibilidad: al final de la relación, el cliente debe recuperar su código, sus accesos, sus datos y su documentación en un formato utilizable. Precisar qué significa «devolver» —un repositorio Git, credenciales de alojamiento, una exportación de base de datos— evita el secuestro involuntario de un proyecto por quien tiene las llaves.
Fin del contrato: separarse sin romperlo todo
Un proyecto puede detenerse antes de su término: prioridades del cliente que cambian, un desacuerdo persistente, una quiebra. La cláusula de resolución prevé quién puede poner fin al contrato, con qué preaviso y con qué consecuencias económicas. El principio equitativo es simple: el trabajo realizado y aceptado se debe, también los gastos ya comprometidos, y los entregables correspondientes se entregan a prorrata del pago. Distinguir la resolución por conveniencia —el cliente cambia de opinión— de la resolución por incumplimiento evita que una sirva de coartada a la otra.
Dos puntos se añaden con provecho. La cláusula de no captación regula el fichaje recíproco de los equipos durante y después del encargo. Y una cláusula de mediación, que impone un intento de acuerdo amistoso antes de cualquier acción judicial, cuesta unas líneas y a menudo ahorra meses de procedimiento: es la cláusula que uno espera no leer nunca, y la que hace respirables a las demás.
| Cláusula | Riesgo cubierto | A precisar |
|---|---|---|
| Alcance y anexos | Ampliación no facturada del encargo | Entregables, exclusiones, aceptación |
| Anticipo e hitos | Tesorería, cliente que se desentiende | Porcentaje, disparadores, plazos |
| Reserva de propiedad | Entrega sin pago | Cesión de derechos al saldar la factura |
| Cesión de derechos | Litigio sobre la propiedad del código | Derechos, soportes, territorio, duración |
| Limitación de responsabilidad | Reclamaciones desproporcionadas | Tope, exclusión de daños indirectos |
| Reversibilidad | Bloqueo al final del contrato | Formatos, accesos, plazo de devolución |
Punto de vigilancia: un acuerdo solo verbal o un simple correo de validación no desaparece en un conflicto, pero deja al juez —o al mediador— interpretar intenciones. Cada cláusula ausente es una zona gris que la otra parte rellenará a su manera el día en que los intereses diverjan.
Lo que hay que recordar
Un buen contrato web no es un documento defensivo redactado contra el cliente: es un marco compartido que explicita las decisiones que el entusiasmo del arranque deja en la sombra. Alcance y anexos para el perímetro, anticipo y reserva de propiedad para el dinero, cesión delimitada para la propiedad intelectual, limitación de responsabilidad y reversibilidad para la salida: estos seis puntos cubren la mayoría de las situaciones que, a falta de escrito, acaban en pulso.
El contrato ideal es corto y legible. Valen más cinco cláusulas entendidas y respetadas que un ladrillo jurídico que nadie relee y que, llegado el día, solo protege a quien lo escribió.
La cláusula que más echo de menos cuando falta es la reserva de propiedad. Al principio de mi vida como freelance entregué un sitio que se puso en producción antes del pago final; recuperar lo que se me debía llevó meses. Desde entonces la regla es simple: los derechos y la puesta en línea siguen al pago, nunca al revés. No es desconfianza, es claridad, y los clientes serios lo entienden al instante. — Simon Janvier
Para profundizar: menciones y cláusulas de un contrato profesional (service-public.fr, en francés).
