In Linux, nearly all drivers are built directly into the Linux kernel and thus are upgraded every time you update the kernel.

The exceptions, such as some WiFi NIC drivers, and GPU drivers, may or may not be upgraded with an apt upgrade depending on a couple factors (such as whether or not the package is "held back"). You can control the installed version of these drivers through Software & Updates --> Additional Drivers.

Please be sure the prerequisites are installed:

sudo apt-get install build-essential linux-headers-generic

Then compile:

cd ~/Scaricati/e1000e-2.5.4/src
make
sudo make install
sudo modprobe -r e1000e && sudo modprobe e1000e

Verify that you are now using the updated driver:

modinfo e1000e | grep version

It ought to report 2.5.4-NAPI. Can you connect now?

You will have built the driver for your currently running kernel only. When Update Manager offers a newer kernel version, also knownn as linux-image, and asks you to reboot, you must re-compile:

cd ~/Scaricati/e1000e-2.5.4/src
make clean
make
sudo make install
sudo modprobe -r e1000e && sudo modprobe e1000e   

Updates on Linux require a restart if they affect the kernel. Drivers are part of the kernel. It's sometimes possible to upgrade a driver on Linux without rebooting, but that doesn't happen often: the peripheral controller by the driver can't be in use during the update, and the new driver version has to be compatible with the running kernel.

Upgrading a driver to a running system where the peripheral controlled by the driver is in use requires that the old driver leaves the peripheral in a state that the new driver is able to start with. The old and new driver must manage the handover of connections from clients as well. This is doable but difficult; how difficult depends on what the driver is driving. For example, a filesystem update without unmounting the filesystem requires the handover of some very complex data structures but is easy to cope with on the hardware side (just flush the buffers before the update, and start over with an empty cache). Conversely, an input driver only has to transmit a list of open descriptors or the like on the client side, but the hardware side requires that the new driver know what state the peripheral is in and must be managed carefully not to lose events.

Updating a driver on a live system is a common practice during development on operating systems where drivers can be dynamically loaded and unloaded, but usually not while the peripheral is in use. Updating a driver in production is not commonly done on OSes like Linux and Windows; I suppose it does get done on high-availability systems that I'm not familiar with.

Some drivers are not in the kernel (for example FUSE filesystems). This makes it easy to update them without updating the rest of the system, but it still requires that the driver not be in use (e.g. instances of the FUSE filesystem have to be unmounted and mounted again to make use of the new driver version).

Linux does have mechanisms to upgrade the kernel without restarting: Ksplice, Kpatch, KGraft. This is technically difficult as the updated version has to be compatible with the old version to a large extent; in particular, its data structures have to have exactly the same binary layout. A few distributions offer this service for security updates. These features are not (yet?) available in the mainline Linux kernel. On a mainline Linux kernel, a driver can be updated only if it's loaded as a module and if the module can be unloaded and the new module is compatible with the running kernel.